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Kubernetes 是 容器 编排 引擎 的 事实 标准 ， 是 继 大 数据 、 云 计算 和 
Docker 之 后 又 一 热门 技术 ， 而 且 未 来 相当 一 段 时 间 内 都 会 非常 流行 。 对 
于 IT 行业 来 说， 这 是 一 项 非常 有 价值 的 技术 。 对 于 IT 从 业者 来 说 ， 和 掌握 
容器 技术 既是 市 场 的 需要 ， 也 是 提升 自我 价值 的 重要 途径 。 


本 书 共 15 章 ， 系 统 介 绍 了 Kubernetes 的 架构 、 重 要 概念 、 安 装 部 署 
方法 、 运 行 管 理应 用 的 技术 、 网 络 存储 管理 、 集 群 监控 和 日 志 管 理 等 重 
要 内 容 。 书 中 通过 大 量 实 操 案例 深入 浅 出 地 讲解 Kubernetes 核 心 搁 术 ， 
是 一 本 从 入 门 到 进 阶 的 实用 Kubernetes 操 作 指 导 手 册 。 读 者 在 学 习 的 过 
程 中 ， 可 以 跟着 教程 进行 操作 ， 在 实践 中 掌握 Kubernetes 的 核心 技能 。 
在 之 后 的 工作 中 ， 则 可 以 将 本 教程 作为 参考 书 ， 按 需 和 查找 相关 知识 点 。 


本 书 主要 面向 微服 务 软件 开发 人 员 ， 以 及 IT 实 施 和 运 维 工 程 师 等 相 
关 人 员 ， 也 适合 作为 高 等 院 校 和 培训 学 校 相关 专业 的 教学 参考 书 。 
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写 在 最 前 面 


《每 天 5 分 钟 玩 转 Kubernetes》 是 一 本 系统 学 习 Kubernetes 的 教程 ， 
有 下 面 两 个 特点 : 





e 系统 讲解 当前 最 流行 的 容器 编排 引擎 Kubernetes 





包括 安装 部 署 、 应 用 管理 、 网 络 、 存 储 、 监 控 、 日 志 管 理 
个 方面 。 





等 多 
。 重 实践 并 兼顾 理论 
通过 大 量 实验 和 操作 市 领 大 家 学 习 Kubernetes。 


为 什么 要 写 这 个 





因为 Kubernetes 非 常 热门 ， 但 学 习 门 槛 高 


2017 年 9 月 ，Mesosphere 宣 布 文 持 Kubermetes; 10 月 ，Docker 宣 布 将 


在 新 版 本 中 加 入 对 Kubernetes 的 原生 支持 。 至 此 ， 容 器 编排 引 苟 领域 的 
三 足 易 立时 代 结 束 ，Kubernetes 赢 得 全 面 胜利 。 


其 实 早 在 2015 年 5 月 ，Kubernetes 在 Google 上 的 搜索 热度 就 已 经 超过 
了 Mesos 和 Docker Swarm， 从 那 之 后 便 是 一 路 奖 升 ， 将 对 手 “ 甩 开 了 十 几 


Alay, AWS, Azure, Google. [HE zi. 腾讯 云 等 主流 公有 云 提 供 
的 是 基于 Kubernetes 的 容器 服务 。Rancher、CoreOS、IBM、Mirantis、 
i Hat、VMWare 等 无 数 厂 商 也 在 大 力 研发 和 推广 基于 
Kubernetes 的 容 絮 CaaS 或 PaaS 产 品 。 可 以 说 ，Kubemetes 是 当前 容器 行 
业 最 热门 的 。 


每 一 轮 新 技术 的 兴起 ， 无 论 对 公司 还 是 个 人 既是 机 会 也 是 挑战 。 这 
项 新 技术 未 来 必 将 成 为 主流 ， 那 么 作为 IT 从 业者 ， 正 确 的 做 法 加 是 尽快 
掌握 。 因 为 : 

(1) 新 技术 意味 独 新 的 市 场 和 新 的 需求 。 初 期 掌握 这 种 技术 的 人 
不 是 很 多 ， 而 市 场 需 求 会 越 来 越 大 ， 因 而 会 形成 供不应求 的 卖方 市 场 ， 
物 以 稀 为 贯 ， 这 对 技术 人 员 将 是 一 个 难得 的 价值 提升 机 会 。 

(2) 学 习 新 技术 需要 时 间 和 精力 ， 早 起 步 早 成 材 。 

机 会 讲 过 了 ， 咀 们 再 来 看 看 挑战 。 


i 新 技术 往往 意味 痢 技 术 上 的 突破 和 创新 ， 会 有 不 少 新 的 概念 和 方 
D 
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算 、 网 络 、 存 储 、 高 可 用 、 监 控 、 日 志 管 理 等 多 个 方面 ， 要 掌握 这 些 新 
技术 对 IT 老兵 尚 有 不 小 难度 ， 更 别 说 新 人 了 。 


写 给 谁 看 





这 套 教 程 的 目标 读者 包括 : 


IT 实施 和 运 维 工程 师 

越 来 越 多 的 应 用 将 以 容 吉 的 方式 在 开发 、 测 试 和 生产 环境 中 运行 。 
掌握 基于 Kubernetes 的 容器 平台 运 维 能 力 将 成 为 实施 和 运 维 工 程 师 的 核 
ven js 


软件 开发 人 员 

基于 容器 的 微服 务 架 构 (Microservice Architecture) 会 逐渐 成 为 开 
发 应 用 系统 的 主流 ， 而 Kubernetes 将 是 运行 微服 务 应 用 的 理想 平台 ， 市 
场 将 需要 大 量具 备 Kubernetes 技 能 的 应 用 程序 开发 人 员 。 

ROR 

CloudMan 坚 信 最 好 的 学 习 方 法 是 分 享 。 编 写 这 本 教程 的 同时 也 是 


对 目 己 学 习 和 实践 Kubernetes 技 术 的 总 结 。 对 于 知识 ， 只 有 把 它 写 出 来 
并 能 够 让 其 他 人 理解 ， 才 能 说 明 目 己 真正 掌握 了 。 
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第 1 音 ” 先 把 Kubernetes 跑 起 来 


Kubernetes (K8s) 是 Google 在 2014 年 发 布 的 一 个 开源 项 目 。 





据说 Google 的 数据 中 心里 运行 着 20 多 亿 个 容器 ， 而 且 Google 十 年 前 
就 开始 使 用 容器 技术 。 


最 初 ，Google 开 发 了 一 个 叫 Borg 的 系统 (现在 命名 为 Omega) 来 调 
度 如 此 庞大 数量 的 容器 和 工作 负载 。 在 积累 了 这 么 多 年 的 经 验 后 ， 
Google 决 定 重 写 这 个 容器 管理 系统 ， 并 将 其 贡献 到 开源 社区 ， 让 全 世界 
都 能 受益 。 

这 个 项 目 就 是 Kubernetes。 人 简单 地 讲 ，Kubernetes 是 Google Omega 的 
开源 版 本 。 


从 2014 年 第 一 个 版 本 发 布 以 来 ，Kubernetes 迅 速 获得 开源 社区 的 追 
fe, fi4hRed Hat、VMware、Canonical 在 内 的 很 多 有 影响 力 的 公司 加 入 
到 开发 和 推广 的 阵营 。 目 前 Kubernetes 已 经 成 为 发 展 最 快 、 市 场 占 有 率 
最 高 的 容器 编排 引擎 产品 。 





Kubernetes 一 直 在 快速 地 开发 和 迭 代 。 本 书 我 们 将 以 v1.7 和 v1.8 为 基 
础 学 习 Kubernetes。 我 们 会 讨论 Kubernetes 重 要 的 概念 和 架构 ， 学 习 
Kubernetes 如 何 编排 容器 ， 包 括 优 化 资源 利用 、 高 可 用 、 滚 动 更 新 、 网 
络 插件 、 服 务 发 现 、 监 控 、 数 据 管 理 、 日 志 管 理 等 。 


下 面 就 让 我 们 开始 Kubernetes 的 探险 之 旅 。 


1.1 ^x 


按照 一 贯 的 学 习 思 路 ， 我 们 会 在 最 短 时 间 内 搭建 起 一 个 可 用 系统 ， 
这 样 就 能 够 尽快 建立 起 对 学 习 对 象 的 感性 认识 。 先 把 玩 起 来 ， 快 速 了 解 
基本 概念 、 功 能 和 使 用 场景 。 

越 是 门槛 高 的 知识 ， 束 越 需要 有 这 人 么 一 个 最 小 可 用 系统 。 如 果 直 接 
上 来 束 学 习 理 论 知 识 和 概念 ， 很 容易 从 入 门 到 放弃 。 

当然 ， 要 搭建 这 么 一 个 可 运行 的 系统 通常 也 不 会 太 容 易 ， 不 过 很 扯 
运 ，Kubernetes 官 网 已 经 为 大 家 准备 好 了 现成 的 最 小 可 用 系统 。 

kubernetes.io 开 发 了 一 个 交互 式 教 程 ， 通 过 Web 浏 览 右 束 能 使 用 预 
先 部 晋 好 的 一 个 Kubernetes 集 群 ， 快 速 体 验 Kubernetes 的 功能 和 应 用 场 
景 ,， 下面 我 束 带 着 大 家 去 玩 一 下 。 


打开 https://kubernetes.io/docs/tutorials/kubernetes-basics/。 


页 面 左边 就 能 看 到 教程 琳 单 ， 如 图 1-1 所 示 。 








kubernetes 





Tutorials 
v Kubernetes Basics 
Overview 
> 1. Create a Cluster 
p> 2. Deploy an App 
> 3. Explore Your App 
> 4. Expose Your App Publicly 
> 5. Scale Your App 
> 6. Update Your App 


图 1-1 


教程 会 指引 大 家 完成 创建 Kubernetes 集 群 、 部 署 应 用 、 访问 应 用 、 
扩展 应 用 、 更 新 应 用 等 最 常见 的 使 用 场景 ， 迅 速 建立 感性 认识 。 


1.2 ”创建 Kubernetes 集 和 群 


点 击 教程 菜单 1. Create a Cluster > Interactive Tutorial - Creating a 
Cluster， 如 图 1-2 所 示 。 


kubernetes 





Tutorials 
v Kubernetes Basics 
Overview 
v 1.Create a Cluster 
Using Minikube to Create a Cluster 
Interactive Tutorial - Creating a Cluster 
2. Deploy an App 
3. Explore Your App 


> 
> 
> 4. Expose Your App Publicly 
p> 5. Scale Your App 

> 


6. Update Your App 


图 1-2 
显示 操作 界面 ， 如 图 1-3 所 示 。 


Terminal T 
Module 1 
Kubernetes Bootcamp Terminal 


Step 1 of 3 = 


>l 








Cluster up and 
running 


We already installed minikube for 
you. Check that it is properly 
installed, by running the minikube 
version command: 


minikube version e 


OK, we can see that minikube is in 
place. 


Start the cluster, by running the 
minikube start command: 


minikube start e 


Great! You now have a running 
Kubernetes cluster in your online 
terminal. Minikube started a virtual 
machine for you, and a Kubernetes f Ol Kata<oda 


Dow running in that ViVi 





图 1-3 
左边 部 分 是 操作 说 明 。 右 边 是 Terminal， 即 命令 终端 窗口 。 


按照 操作 说 明 ， 我 们 在 Terminal 中 执行 minikube ”start， 然 后 执行 
kubectl get nodes， 这 样 就 创建 好 了 一 个 单 节点 的 kubernetes 集 群 ， 如 图 1- 
4 所 示 。 


Terminal 中 


Kubernetes Bootcamp Terminal 
> 


> minikube start 
Starting local Kubernetes cluster... 


> kubectl get nodes 
NAME STATUS AGE 
host01 Ready 7s 


> hostname 
e968725c1697 


> 





图 1-4 


集群 的 唯一 节点 为 host01， 需 要 注意 的 是 当前 执行 命令 的 地 方 并 不 
是 host01。 我 们 是 通过 Kubernetes 的 命令 行 工 具 kubectl 远 程 管 理 集 群 。 


执行 kubectl cluster-info 查 看 集群 信息 ， 如 图 1-5 所 示 。 


> kubectl cluster-info 
Kubernetes master is running at http: ZAnoStels 8080 
es is running at http: //host01:8080/api/v1/proxy/namespaces e be-system/services/heapster 
kubernetes-dashboard is running at http://host01:8080/a aps VAY MEE pac 
moni: tor ing-grafana is running at http://host01:8080/api/v1/p abe 


service g-grafana 
monitoring-influxdb is running at http:/ I asta BEN VAIDE ube-sys toring-influxdb 


To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. 





> 


图 1-5 
heapster、kubernetes-dashboard 都 是 集群 中 运行 的 服务 。 


注意 : 为 节省 篇 幅 ， 在 后 面 的 演示 中 ， 我 们 将 简化 操作 步 又， 详细 
的 说 明和 完整 步骤 请 参考 官网 在 线 文 档 。 





kubectl run kubernetes-bootcamp \ 
- image-docker.io/jocatalin/kubernetes-bootcamp:v1 \ 
- port-8080 


这 里 我 们 通过 kubectl run 部 署 了 一 个 应 用 ， 命 名 为 kubernetes- 
bootcamp， 如 图 1-6 所 示 。 


Docker 镜 像 通过 --image 指 定 。 
--port 设 置 应 用 对 外 服务 的 端口 。 


Terminal + 


> kubectl run kubernetes-bootcamp \ 
> ——image=docker.io/jocatalin/kubernetes—bootcamp:v1 \ 


> —-port-8080 
deployment "kubernetes-bootcamp" created 


di. 





图 1-6 
这 里 Deployment 是 Kubernetes 的 术语 ， 可 以 理解 为 应 用 。 
Kubernetes 还 有 一 个 重要 术语 Pod。 
Pod 是 容器 的 集合 ， 通 常会 将 紧密 相关 的 一 组 容器 放 到 一 个 Pod 中 ， 
同一 个 Pod 中 的 所 有 容器 共享 卫 地 址 和 Port 空 间 ， 也 束 是 说 它们 在 一 个 


network namespace 中 。 


Pod 是 Kubernetes 调 度 的 最 小 单位 ， 同 一 Pod 中 的 容器 始终 被 一 起 调 





BE. 
运行 kubectl get pods， 查 看 当前 的 Po0d， 如 图 1-7 所 示 。 


> kubectl get pods 
NAME READY STATUS RESTARTS AGE 


kubernetes-bootcamp-390780338-q9p1t 1/1 Running 0 11m 


> 





图 1-7 


kubernetes-bootcamp-390780338-q9plt 就 是 应 用 的 Pod。 


1.4 访问 应 用 


默认 情况 下 ， 所 有 Pod 只 能 在 集群 内 部 访问 。 对 于 上 面 这 个 例子 ， 
要 访问 应 用 只 能 直接 访问 容器 的 8080 端 口 。 为 了 能 够 从 外 部 访问 应 用 ， 
我 们 需要 将 容器 的 8080 端 口 映 射 到 节点 的 端口 。 

执行 如 下 命令 ， 结 果 如 图 1-8 所 示 。 
kubectl expose deployment/kubernetes-bootcamp \ 


--type="NodePort" \ 
--port 8080 


> kubectl expose deployment/kubernetes-bootcamp V 
> --type-"NodePort" X 
> —-port 8080 


service "kubernetes—bootcamp" exposed 





> 


图 1-8 


执行 命令 kubectl get services， 可 以 查看 应 用 被 映射 到 节点 的 哪个 并 
口 ， 如 图 1-9 所 示 。 
> kubectl get services 


NAME CLUSTER-IP EXTERNAL-IP PORT(S) 
kubernetes 10.0.0.1 <none> 443/TCP 


kubernetes-bootcamp 10.0.0.131 «nodes» 8080:32320/TCP 1m 


> 





图 1-9 
这 里 有 两 个 service， 可 以 将 service 暂 时 理解 为 端口 映射 ， 后面 我 们 
会 详细 讨论 。 


Kubernetes 是 默认 的 service， 和 暂时 不 用 考虑 。kubernetes-bootcamp 是 
我 们 应 用 的 service，8080 问 口 已 经 映射 到 host01 的 32320 端 口 ， 问 口号 是 
随机 分 配 的 ， 可 以 执行 如 下 命令 访问 应 用 ， 结 果 如 图 1-10 所 示 。 


curl host01:32320 


» curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-q9p1t | v=1 





图 1-10 


1.5 Scale 心 用 


默认 情况 下 应 用 只 会 运行 一 个 副本 ， 可 以 通过 kubectl 
deployments 碍 看 副本 数 ， 如 图 1-11 所 示 。 


> kubectl get deployments 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 


kubernetes-bootcamp 1 1 1 1 14m 





> 


图 1-11 
执行 如 下 命令 将 副本 数 增加 到 3 个 ， 如 图 1-12 所 示 。 
kubectl scale deployments/kubernetes-bootcamp --replicas-3 


> kubectl scale deployments/kubernetes-bootcamp —-replicas-3 
deployment "kubernetes-bootcamp" scaled 


> 


> kubectl get deployments 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
kubernetes-bootcamp 3 3 3 3 17m 





> 


图 1-12 


通过 kubectl get pods 可 以 看 到 当前 Pod 增 加 到 3 个 ， 如 图 1-13 所 示 。 


> kubectl get pods 


NAME STATUS RESTARTS AGE 
kubernetes-bootcamp-390780338-12sbg Running im 


kubernetes—boot camp-—390780338-q9p1t Running 19m 


kubernetes-bootcamp-390780338-swvp7 Running 1m 


> 





图 1-13 





get 


通过 curl 访 问 应 用 ， 可 以 看 到 每 次 请 求 发 送 到 不 同 的 Pod，3 个 副本 


轮 询 处 理 ， 这 样 就 实现 了 负载 均衡 ， 如 图 1-14 所 示 。 


» curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-12sbg | 


» curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-swvp7 | 


» curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-q9p1t | 


> curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-12sbg | 


> 





图 1-14 


要 scale down 也 很 方便 ， 执 行 下 列 命令 ， 结 果 如 图 1-15 所 示 。 
kubectl scale deployments/kubernetes-bootcamp --replicas-2 


» kubectl scale deployments/kubernetes-bootcamp —-replicas-2 
deployment "kubernetes-bootcamp" scaled 


» kubectl get deployments 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
kubernetes-bootcamp 2 2 2 2 25m 


> kubectl get pods 
NAME STATUS RESTARTS 
kubernetes-bootcamp-390780338-12sbg Running 0 
kubernetes-bootcamp-390780338-q9p1t Running 0 
kubernetes-bootcamp-390780338-swvp7 Terminating | 0 





图 1-15 


从 图 1-15 中 可 以 看 到 ， 其 中 一 个 副本 被 删除 了 。 


1.6 ”滚动 更 新 


当前 应 用 使 用 的 image 版 本 为 v1， 执 行 如 下 命令 将 其 升级 到 v2， 


果 如 图 1-16 所 示 。 


kubectl set image deployments/kubernetes-bootcamp 
kubernetes-bootcamp-jocatalin/kubernetes-bootcamp:v2 


» kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp-jocatalin/kubernetes-bootcamp: v2 


deployment "kubernetes-bootcamp" image updated 


» kubectl get pods 
NAME 
kubernetes-bootcamp-2100875782-2q5k8 
kubernetes-bootcamp-2100875782-sbwkc 
kubernetes-bootcamp-390780338-12sbg 
kubernetes-bootcamp-390780338-q9p1t 


» kubectl get pods 


NAME 
kubernetes-bootcamp-2100875782-2q5k8 
kubernetes-bootcamp-2100875782-sbwkc 
kubernetes-bootcamp-390780338-12sbg 
kubernetes-bootcamp-390780338-q9p1t 


> kubectl get pods 
NAME 
kubernetes-bootcamp-2100875782-2q5k8 
kubernetes-bootcamp-2100875782-sbwkc 


> 


STATUS RESTARTS 
ContainerCreating 0 
ContainerCreating 6 
Terminating 0 
Running 9 


STATUS RESTARTS 
Running e 
Running 0 
Terminating 0 
Terminating 0 


STATUS RESTARTS 
Running @ 
Running 0 





图 1-16 








X 
结 


通过 kubectl get pods 可 以 观察 滚动 更 新 的 过 程 : v1 的 Pod 被 逐个 市 
除 ， 同 时 启动 了 新 的 v2 Pod。 更 新 完成 后 访问 新 版 本 应 用 ， 如 图 1-17 所 


> curl host01:32320 


Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-2100875782-sbwkc | v=2 


> curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-2100875782-2q5k8 | v=2 


> 





图 1-17 


如 果 要 回 退 到 v1 版 本 也 很 容易 ， 执 行 kubectl rollout undo 命 令 ， 


如 图 1-18 所 示 。 


kubectl rollout undo deployments/kubernetes-bootcamp 


结果 


» kubectl rollout undo deployments/kubernetes-bootcamp 
deployment "kubernetes-bootcamp" rolled back 


> kubectl get pods 
NAME STATUS RESTARTS 
kubernetes-bootcamp-2100875782-2q5k8 Running 0 
kubernetes-bootcamp-2100875782-sbwkc Terminating 
kubernetes-bootcamp-390780338-9kvj j ContainerCreating 
kubernetes—bootcamp-390780338-hmcgb ContainerCreating 


[1-18 


验证 版 本 已 经 回 退 到 v1， 如 图 1-19 所 示 。 





> curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-hmcgb | v=1 


» curl host01:32320 


Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-9kvjj | v=1 





图 1-19 


1.7 gi 


人 至此， 我 们 已 经 通过 官网 的 交互 式 教 程 快速 体验 了 Kubernetes 的 功 
能 和 使 用 方法 。 本 书 的 其 余 章 市 将 详细 讨论 Kubernetes 的 架构 、— 典 型 的 
部 署 方 法 、 容 恬 编 排 能 力 、 网 络 方案 、 监 挖 方案， 帮助 大 家 全 面 掌握 
Kubernetes 的 核心 技能 。 


在 实践 之 前 ， 必 须 先 学 习 Kubernetes 的 几 个 重要 概念 ， 它 们 是 组 成 
Kubernetes 集 群 的 基石 。 


1. Cluster 


Cluster 是 计算 、 存 储 和 网 络 资源 的 集合 ，Kubernetes 利 用 这 些 资源 
运行 各 种 基于 容器 的 应 用 。 


2. Master 





Master 是 Cluster 的 大 脑 ， 它 的 主要 职责 是 调度 ， 即 决定 将 应 用 放 在 
哪里 运行 。Master 运 行 Linux 操 作 系 统 ， 可 以 是 物理 机 或 者 虚拟 机 。 为 了 
实现 高 可 用 ， 可 以 运行 多 个 Master。 


3. Node 

Node 的 职责 是 运行 容器 应 用 。Node 由 Master 管 理 ，Node 负 责 监 控 
并 汇报 容器 的 状态 ， 同时 根据 Master 的 要 求 管理 容器 的 生命 周期 。 Node 
运行 在 Linux 操 作 系 统 上 ， 可 以 是 物理 机 或 者 是 虚拟 机 。 


在 前 面 交 互 式 教 程 中 ， 我 们 创建 的 Cluster 只 有 一 个 主机 host01， 它 
既是 Master 也 是 Node， 如 图 2-1 所 示 。 





Terminal + 


Kubernetes Bootcamp Terminal 
> 


> minikube start 
Starting local Kubernetes cluster... 


> kubectl get nodes 
STATUS AGE 
Ready 7s 


> hostname 
e968725c1697 


> 





4. Pod 


Pod 是 Kubernetes 的 最 小 工作 单元 。 每 个 Pod 包 含 一 个 或 多 个 容器 。 
Pod 中 的 容器 会 作为 一 个 整体 被 Master 调 度 到 一 个 Node 上 运行 。 


Kubernetes 引 入 Pod 主 要 基于 下 面 两 个 目的 : 

(1) 可 管理 性 。 

有 些 容器 天 生 束 是 需要 紧密 联系 ， 一 起 工作 。Pod 提 供 了 比 容器 更 
高 层次 的 抽象 ， 将 它们 封装 到 一 个 部 署 单元 中 。Kubernetes 以 Pod 为 最 小 
单位 进行 调度 、 扩 展 、 共 享 资 源 、 管 理 生 命 周期 。 

(2) 通信 和 资源 共享 。 

Pod 中 的 所 有 容器 使 用 同一 个 网 络 namespace， 即 相同 的 了 地址 和 
Port 空 间 。 它 们 可 以 直接 用 localhost 通 信 。 同 样 的 ， 这 些 容 器 可 以 共享 
存储 ， 当 Kubernetes 挂 载 volume 到 Pod， 本 质 上 是 将 volume 挂 载 到 Pod 中 
BETA SE s 

Pods 有 两 种 使 用 方式 : 

(1) 运行 单一 容器 。 

one-container-per-Pod 是 Kubernetes 最 常见 的 模型 ， 这 种 情况 下 ， 只 


是 将 单个 容器 简单 封装 成 Pod。 即 便 是 只 有 一 个 容器 ，Kubernetes 管 理 的 
也 是 Pod 而 不 是 直接 管理 容器 。 











(2) 运行 多 个 容器 。 
问题 在 于 : 哪些 容器 应 该 放 到 一 个 Pod 中 ? 
答案 是 : 这 些 容器 联系 必须 非常 紧密 ， 而 且 需 要 直接 共享 资源 。 


举 个 例子 ， 如 图 2-2 所 示 ， 这 个 Pod 包 含 两 个 容器 : 一 个 是 File 
Puller， 一 个 是 Web Server. 


Consumers 
Manager 
File Web 
Puller Server 


图 2-2 


File Puller 会 定期 从 外 部 的 Content Manager 中 拉 取 最 新 的 文件 ， 将 其 
存放 在 共享 的 volume 中 。Web Server 从 volume 读 取 文 件 ， 响 应 Consumer 
的 请 求 。 


这 两 个 容器 是 紧密 协作 的 ， 它 们 一 起 为 Consumer 提 供 最 新 的 数据 ; 
同时 它们 也 通过 volume 共 享 数 据 ， 所 以 放 到 一 个 Pod 是 合适 的 。 
再 来 看 一 个 反例 : 是 否 需 要 将 Tomcat 和 MySQL 放 到 一 个 Pod 中 ? 


Tomcat 从 MySQL 读 取 数 据 ， 它 们 之 间 需 要 协作 ， 但 还 不 全 于 需要 
放 到 一 个 Pod 中 一 起 部 团 、 一 起 启动 、 一 起 仿 止 。 同 时 它们 之 间 是 通过 
JDBC 交 换 数 据 ， 并 不 是 直接 共享 存储 ， 所 以 放 到 各 目的 Pod 中 更 合适 。 























5. Controller 


Kubernetes 通 常 不 会 直接 创建 Pod， 而 是 通过 Controller 来 管理 Pod 
的 。Controller 中 定义 了 Pod 的 部 四 特性 ， 比 如 有 几 个 副本 、 在 什么 样 的 
Node 上 运行 等 。 为 了 满足 不 同 的 业务 场景 ，Kubernetes 提 供 了 多 种 
Controller， 包 括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、 


Job 等 ， 我 们 逐一 讨论 。 


(1) Deployment 是 最 常用 的 Controller， 比 如 在 线 教程 中 就 是 通过 
创建 Deployment 来 部 署 应 用 的 。Deployment 可 以 管理 Pod 的 多 个 副本 ， 
并 确保 Pod 按 照 期 望 的 状态 运行 。 


(2) ReplicaSet 实 现 了 Pod 的 多 副本 管理 。 使 用 Deployment 时 会 自 
动 创 建 ReplicaSet， 也 就 是 说 Deployment 是 通过 ReplicaSet 来 管理 Pod 的 多 
个 副本 的 ， 我 们 通常 不 需要 直接 使 用 ReplicaSet。 


(3) DaemonSet 用 于 每 个 Node 最 多 只 运行 一 个 Pod 副 本 的 场景 。 下 
如 其 名 称 所 揭示 的 ，DaemonSet 通 常用 于 运行 daemon。 


(4) StatefuleSet 能 够 保证 Pod 的 每 个 副本 在 整个 生命 周期 中 名 称 是 
不 变 的 ， 而 其 他 Controller 不 提供 这 个 功能 。 当 某 个 Pod 发 生 故 障 需 要 删 
除 并 重新 启动 时 ，Pod 的 名 称 会 发 生变 化 ， 同 时 StatefuleSet 会 保证 副本 
按照 固定 的 顺序 启动 、 更 新 或 者 删除 。 


(5) Job 用 于 运行 结束 就 删除 的 应 用 ， 而 其 他 Controller 中 的 Pod 通 
和 是 长 期 持续 运行 。 








6. Service 


Deployment 可 EAE P BIA, APAA A GIP, 97 
访问 这 些 副 本 呢 ? 


通过 Pod 的 IP 吗 ? 


要 知道 Pod 很 可 能 会 被 频 索 地 销毁 和 重启 ， 它 们 的 下 会 发 生变 化 ， 
用 IP 来 访问 不 太 现 实 。 


答案 是 Service。 


Kubernetes ”Service 定 义 了 外 界 访 问 一 组 特定 Pod 的 方式 。Service 有 
自己 的 IP 和 端口 ，Service 为 Pod 提 供 了 负载 均衡 。 


Kubernetes 运 行 容器 (Pod) 与 访问 容器 (Pod) 这 两 项 任务 分 别 由 
Controller 和 Service 执 行 。 


7. Namespace 


如 果 有 多 个 用 户 或 项 目 组 使 用 同一 个 Kubernetes _ Cluster， 如 何 将 他 
们 创建 的 Controller、Pod 等 资源 分 开 呢 ? 


答案 就 是 Namespace。 

Namespace 可 以 将 一 个 物理 的 Cluster 逻 辑 上 划分 成 多 个 虚拟 
Cluster， 每 个 Cluster 就 是 一 个 Namespace。 不 同 Namespace 里 的 资源 是 完 
全 隔离 的 。 

Kubernetes 默 认 创建 了 两 个 Namespace， 如 图 2-3 所 示 。 


> kubectl get namespace 
NAME STATUS AGE 
default Active 17s 


kube-system Active 17s 


> 





图 2-3 


e default: 创建 资源 时 如 果 不 指 定 ， 将 被 放 到 这 个 Namespace 中 。 
e kube-system: Kubernetes 上 自己 创建 的 系统 资源 将 放 到 这 个 
Namespace 中 。 


^34 Ux Kubernetes Cluster 





本 章 我 们 将 部 署 三 个 节点 的 Kubernetes Cluster， 如 图 3-1 所 示 。 


图 3-1 





k8s-master 是 Master，k8s-node1 和 Kk8s-node2 是 Node。 


所 有 节点 的 操作 系统 均 为 Ubuntu “16.04， 当 然 其 他 Linux 也 是 可 以 


官方 安装 文档 可 以 参考 
https://kubernetes.io/docs/setup/independent/install-kubeadm/. 


注意 : Kubernetes 几 乎 所 有 的 安装 组 件 和 Docker 镜 像 都 放 在 Google 
自己 的 网 站 上 ， 这 对 国内 的 同学 可 能 是 个 不 小 的 障碍 。 建 议 是 : 网 络 障 
碍 都 必须 想 办 法 克服 ， 不 然 连 Kubernetes 的 门 都 进 不 了 。 





3.1 安装 Docker 





所 有 市 点 都 需要 安 六 Docker。 


apt-get update && apt-get install docker.io 


3.2 ”安装 kubelet、kubeadm 和 kubectl 





在 所 有 节点 上 安装 kubelet、kubeadm 和 kubectl。 


e kubelet 运 行 在 Cluster 所 有 市 点 上 ， 人 负责 启动 Pod 和 容 占 。 

e kubeadm 用 于 初始 化 Cluster。 

e kubectl 是 Kubernetes 命 令 行 工具 。 通 过 kubect 可 以 部 普 和 管理 应 
用 ， 碍 看 各 种 资源 ， 创 建 、 删 除 和 更 新 各 种 组 件 。 


apt-get update && apt-get install -y apt-transport-https 

curl -S https://packages.cloud.google.com/apt/doc/apt - 
key.gpg | apt-key add - 

cat ««EOF >/etc/apt/sources.list.d/kubernetes. list 

deb http://apt.kubernetes.io/ kubernetes-xenial main 

EOF 

apt-get update 

apt-get install -y kubelet kubeadm kubectl 


3.3 ”用 kubeadm 创 建 Cluster 


完整 的 官方 文档 可 以 参考 
https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/. 


3.3.1 初始 化 Master 


在 Master 上 执行 如 下 命令 : 


kubeadm init --apiserver-advertise-address 192.168.56.105 
- -pod-network-cidr-10.244.0.0/16 


--apiserver-advertise-address 指 明 用 Master 的 哪个 interface 与 Cluster 的 
其 他 节点 通信 。 如 果 Master 有 多 个 interface， 建 议 明 确 指 定 ， 如 果 不 指 
定 ，kubeadm 会 自动 选择 有 默认 网 关 的 interface。 


--pod-network-cidr 指 定 Pod 网 络 的 范围 。Kubernetes 支 持 多 种 网 络 方 
案 ， 而 且 不 同 网 络 方案 对 --pod-network-cidr 有 自己 的 要 求 ， 这 里 设置 为 
10.244.0.0/16 是 因为 我 们 将 使 用 flannel 网 络 方案 ， 必 须 设置 成 这 个 
CIDR。 在 后 面 的 实践 中 我 们 会 切换 到 其 他 网 络 方案 ， 比 如 Canal。 


初始 化 过 程 如 图 3-2 所 示 。 





root@k8s-master ;~# 

root@k8s-master:~# kubeadm init --apiserver-advertise-address 192.168,56.105 --pod-network-cidr-10.244,0.0/16 
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters. 

[init] Using Kubernetes version: v1.7.4 

[init] Using Authorization modes: [Node RBAC] 

[preflight] Running pre-flight checks 

[preflight] Starting the kubelet service 

[kubeadm] WARNING: starting in 1.8, tokens expire after 24 hours by default (if you require a non-expiring token use --token-ttl 0) 
[certificates] Generated CA certificate and key. 

[certificates] Generated API server certificate and key. 

[certificates] API Server serving cert is signed for DNS names [k8s-master kubernetes kubernetes.default kubernetes.default.svc kubernetes .| 
96.0.1 192.168.56.105] 

[certificates] Generated API server kubelet client certificate and key. 

[certificates] Generated service account token signing key and public key. 

[certificates] Generated front-proxy CA certificate and key. 

[certificates] Generated front-proxy client certificate and key. 

[certificates] Valid certificates and 

[kubeconfig] Wrote KubeConfig file to 

[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf" 

[kubeconfig] Wrote KubeConfig file to di A 

[kubeconfig] Wrote KubeConfig file to di etc/kubernetes/scheduler.conf" 

[apiclient] Created API client, waiting for the control plane to become ready 

[apiclient] All control plane components are healthy after 26.505992 seconds 

[token] Using token: d38001.13653e584ccc1980 

[apiconfig] Created RBAC rules 

[addons] Applied essential addon: kube-proxy 

[addons] Applied essential addon: kube-dns 


Your Kubernetes master has initialized successfully! 

To start using your cluster, you need to run (as a regular user): 
mkdir -p $HOME/.kube 
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config 
sudo chown $Cid -u):$Cid -g) $HOME/.kube/config 

You should now deploy a pod network to the cluster. 


Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at: 
http://kubernetes . io/docs/admin/addons/ 


You can now join any number of machines by running the following on each node 
las root: 


kubeadm join --token d38a01.13653e584ccc1980 192.168.56.105:6443 


root@k8s-master :~# 





图 3-2 
(1) kubeadm 执 行 初始 化 前 的 检查 。 
(2) 生成 token 和 证 书 。 
(3) 生成 KubeConfig 文 件 ，kubelet 需 要 用 这 个 文件 与 Master 通 信 。 


(4) 安装 Master 组 件 ， 会 从 Google 的 Registry 下 载 组 件 的 Docker 镜 
像 。 这 一 步 可 能 会 花 一 些 时 间 ， 主 要 取决 于 网 络 质量 。 


(5) 安装 附加 组 件 kube-proxy 和 kube-dns。 
(6) Kubernetes Master 初 始 化 成 功 。 

(7) 提示 如 何 配置 kubect， 后 面 会 实践 。 
(8) 提示 如 何 安装 Pod 网 络 ， 后 面 会 实践 。 


(9) 提示 如 何 注册 其 他 节点 到 Cluster， 后 面 会 实践 。 


3.3.2 ”配置 kubectl 


kubect 是 管理 Kubernetes _ Cluster 的 命令 行 工 具 ， 前 面 我 们 已 经 在 所 
有 的 节点 安装 了 kubectl。Master 初 始 化 完成 后 需要 做 一 些 配置 工作 ， 然 
后 kubectl 就 能 使 用 了 。 


依照 kubeadm init 输 出 的 第 7 步 提 示 ， 推 荐 用 Linux 普 通用 户 执行 
kubectl (root 会 有 一 些 问 题 ) 。 


我 们 为 用 户 ubuntu 配 置 kubectl: 


su - ubuntu 

mkdir -p $HOME/.kube 

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config 
sudo chown $(id -u):$(id -g) $HOME/.kube/config 


为 了 使 用 更 便捷 ， 启 用 kubectl 命 令 的 自动 补 全 功能 : 


echo "source «(kubectl completion bash)" >> -/.bashrc 


RPE, Hj P ubuntu3 n] LE H kubectl f . 





3.3.3 ”安装 Pod 网 络 


要 让 Kubernetes _ Cluster 能 够 工作 ， 必 须 安 装 Pod 网 络 ， 否 则 Pod 之 间 
无 法 通信 。 


Kubernetes 支 持 多 种 网 络 方案 ， 这 里 我 们 先 使 用 flannel， 后 面 还 会 
讨论 Canal。 


执行 如 下 命令 部 署 flannel， 如 图 3-3 所 示 。 


kubectl apply - 
f https://raw.githubusercontent.com/coreos/flannel/master/Documen 
flannel. ym1l 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml 
cluste Lo ^ ted 


configi g” created 
daemonset "kube-flannel-ds" created 
ubuntu@k8s-master : ~$ 





3.3.4 添加 k8s-node1 和 Kk8s-node2 


在 k8s-node1 和 k8s-node2 上 分 别 执行 如 下 命令 ， 将 其 注册 到 Cluster 
中 : 


kubeadm join --token d38a01.13653e584ccc1980 192.168.56.105:6443 


这 里 的 --token 来 自前 面 kubeadm init 输 出 的 第 9 步 提示 ， 如 果 当 时 没 
有 记录 下 来 ， 可 以 通过 kubeadm token list 查 看 ， 如 图 3-4 所 示 。 


root@k8s-master:~# 
root@k&s-master:~# kubeadm token list 
TOKEN TTL EXPIRES USAGES DESCRIPTION 





4d38201.13653e584ccc1980 — «forever» <never> authentication,signing The default bootstrap token generated by 'kubeadm init'. 


root@k8s-master:~# 
图 3-4 


kubeadm join 执行 如 图 3-5 所 示 。 


root@k8s-nodel : ~# 
root@k8s-nodel:~# kubeadm join --token d38a01.13653e584ccc1980 192.168.56.105:6443 
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters. 
[preflight] Running pre-flight checks 
[preflight] Starting the kubelet service 
[discovery] Trying to connect to API Server "192.168.56.105:6443" 
[discovery] Created cluster-info discovery client, requesting info from "https://192.168.56.105:6443" 
[discovery] Cluster info signature and contents are valid, will use API Server "https://192.168.56.105:6443" 
[discovery] Successfully established connection with API Server "192.168.56.105:6443" 
[bootstrap] Detected server version: v1.7.4 
[bootstrap] The server supports the Certificates API (certificates.k8s.io/vibetal) 
[esr] Created API client to obtain unique certificate for this node, generating keys and certificate signing request 
[esr] Received signed certificate from the API server, generating KubeConfig... 
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet. conf" 
Node join complete: 
* Certificate signing request sent to master and response 
received. 
* Kubelet informed of new secure connection details. 


Run 'kubectl get nodes' on the master to see this machine join. 


root@k8s-nodel :~# 
图 3-5 


根据 提示 ， 我 们 可 以 通过 kubectl get nodes 查 看 节点 的 状态 ， 如 图 3- 
6 所 示 。 





ubuntu@k8s-master:~$ kubectl get nodes 
NAME STATUS AGE VERSION 


k8s-master NotReady 45m v1.7.4 

k8s-node1 NotReady 59s v1.7.4 

k8s-node2 NotReady 6s v1.7.4 
图 3-6 











目前 所 有 点 都 是 NotReady， 这 是 因为 每 个 太 点 都 需要 局 动 在 干 组 





件 ， 这 些 组 件 都 是 在 Pod 中 运行 ， 需 要 首先 从 Google 下 载 镜像 。 我 们 可 
以 通过 如 下 命令 查看 Pod 的 状态 ， 如 图 3-7 所 示 。 


kubectl get pod --all-namespaces 


ubuntu@k8s-master:~$ kubectl get pod --all-namespaces 
NAME R STATUS RESTARTS 
etcd-k8s-master Running 
kube-apiserver-k8s-master Running 
kube-controller-manager-k8s-master Running 
kube-dns-2425271678-1z3pv Pending 
kube-flannel-ds-cqbpb ContainerCreating 


kube-flannel-ds-v@p3x ImagePullBackOff 

kube-flannel-ds-xk49w ContainerCreating 

kube-proxy-16mg9 ContainerCreating 

kube-proxy-wc4jQ Running 

kube-proxy-x15gd ContainerCreating 

kube-scheduler-k8s-master Running 
ubuntuek8s-master : ~$ 


GeGeeGeeGeGGGQG 





Pending、ContainerCreating、ImagePullBackOfft 都 表明 Pod 没 有 就 
绪 ，Running 才 是 惑 绪 状 态 。 我 们 可 以 通过 kubectl describe pod «Pod 
Name> 码 看 Pod 的 具体 情况 ， 比 如 


kubectl describe pod  kube-flannel-ds-vOp3x  --namespace-kube- 
system 


结果 如 图 3-8 所 示 。 





为 了 节省 篇 幅 ， 这 里 只 截取 命令 输出 的 最 后 部 分 ， 可 以 看 到 在 下 载 
image 时 和 失败， 如 果 网 络 质量 不 好 ， 这 种 情况 是 很 销 见 的 。 我 们 可 以 耐 
心 等 待 ， 因 为 Kubernetes 会 重 试 ， 我 们 也 可 以 上 自己 手动 执行 docker pull 去 
下 载 这 个 镜像 。 


等 待 一段 时 间 ，image 成 功 下 载 后 ， 所 有 Pod 都 会 处 于 Running 状 
态 ， 如 图 3-9 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod --all-namespaces 

NAMESPACE NAME READY STATUS RESTARTS AGE 
kube-system etcd-k8s-master 1/1 Running 0 10m 
kube-system ^ kube-apiserver-k8s-master T/E Running 10m 
kube-system X kube-controller-manager-k8s-master 1/1 Running 10m 
kube-system kube-dns-2425271678-1z3pv 3/3 Running ih 
kube-system kube-flannel-ds-cqbpb 2/2 Running 18m 
kube-system ^ kube-flannel-ds-v0p3x 272 Running 21m 
kube-system kube-flannel-ds-xk49w 2/2 Running 17m 
kube-system kube-proxy-16mg9 1/1 Running 18m 
kube-system ^ kube-proxy-wc4j0 1/1 Running ih 
kube-system ^ kube-proxy-xl5gd 1⁄1 Running 17m 
kube-system kube-scheduler-k8s-master 1/1 Running 10m 
ubuntu@k8s-master : ~$ 

图 3-9 


这 时 ， 所 有 的 节点 都 已 经 准备 好 了 ，Kubernetes _ Cluster 创建 成 功 ， 
如 图 3-10 所 示 。 
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ubuntu@k&s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get nodes 
NAME STATUS AGE VERSION 
k8s-master Ready 1h v1.7.4 


k8s-node1 Ready 18m v1.7.4 
k8s-node2 Ready 17m v1.7.4 
ubuntu@k8s-master : ~$ 





图 3-10 


3.4 小结 


AE SEE kubeadm rii 了 三 节点 的 Kubernetes 集 群 ， 后 面 章节 我 们 
将 在 这 个 实验 环境 中 学 习 Kubernetes 的 各 项 技术 。 


第 4 瘟 Kubernetes2Z £j 





Kubernetes Cluster 由 Master 和 Node 组 成 ， 节 点 上 运行 着 若干 
Kubernetes 服 务 。 


4.1 Master | = 


MasterzéKubernetes Cluster 的 大 脑 ， 运 行 着 的 Daemon 服 务 包括 kube- 
apiserver、kube-scheduler、kube-controller-manager、etcd 和 Pod 网 络 “〈 例 
如 flannel) ， 如 图 4-1 所 示 。 


API Server 
Ex © 
WET (Tg 
etcd 


4 flannel 


图 4-1 





1. API Server (kube-apiserver ) 


API Server 提 供 HTTP/HTTPS RESTful API, HUKubernetes API. API 
ServerzéKubernetes _ Cluster 的 前 端 接口 ， 各 种 客户 端 工具 〈CLI 或 UI) 以 
及 Kubernetes 其 他 组 件 可 以 通过 它 管 理 Cluster 的 各 种 资源 。 


2. Scheduler (kube-scheduler) 


Scheduler 负 贡 决 定 将 Pod 放 在 哪个 Node 上 运行 。Scheduler 在 调度 时 
会 充分 考虑 Cluster 的 拓扑 结构 ， 当 前 各 个 节点 的 负载 ， 以 及 应 用 对 高 可 
用 、 人 性能、 数据 杀 和 性 的 需求 。 


3. Controller Manager (kube-controller-manager) 


Controller Manager 负 责 管 理 Cluster 各 种 资源 ， 保 证 资源 处 于 预期 的 
状态 。Controller Manager 由 多 种 controller 组 成 ， 包 括 replication 


controller, endpoints controller, namespace controller、serviceaccounts 
controller® . 


不 同 的 controller 管 理 不 同 的 资源 。 例 如 ，replication controller® 38 
Deployment、StatefulSet、DaemonSet 的 生命 周期 ，namespace controller 
管理 Namespace 资 源 。 

4. etcd 


etcd 负 责 保 存 Kubernetes Cluster 的 配置 信息 和 各 种 资源 的 状态 信 
。 当 数据 发 生变 化 时 ，etcd 会 快速 地 通知 Kubernetes 相 关 组 件 。 


5. Pod 网 络 


CI 


Pod 要 能 够 相互 通信 ，Kubernetes Cluster/^ 2 783 Pod 28, flannel 
是 其 中 一 个 可 选 方案 。 


以 上 是 Master 上 运行 的 组 件 ， 下 面 我 们 接着 讨论 Node。 


4.2 Node 节 点 


Node 是 Pod 运 行 的 地 方 ，Kubernetes 支 持 Docker、rkt 等 容器 
Runtime。Node 上 运行 的 Kubernetes 组 件 有 kubelet、kube-proxy 和 Pod 网 
络 〈 例 如 flannel) ， 如 图 4-2 所 示 。 


4 flannel 


图 4-2 





1. kubelet 


kubelet 是 Node 的 agent 当 Scheduler 确 定 在 A“ Node [38 47 Pod 后 ， 
会 将 Pod 的 具 体 配置 信息 fc (image、vVolume 等 ) 发 送 给 该 节点 的 kubelet， 
kubelet 根 据 这 些 信息 创建 和 运行 容器 ， 并 向 Mester 报 告 运 至 行 状态 。 


2. kube-proxy 

service 在 逻辑 上 代表 了 后 端的 多 个 Pod， 外 界 通过 service 访 问 Pod。 
service 接 收 到 的 请 求 是 如 何 转 发 到 Pod 的 呢 ? 这 就 是 kube-proxy 要 完成 的 
SEES 


每 个 Node 都 会 运行 kube-proxy 服 务 ， 它 负责 将 访问 service 的 


TCP/UPD 数 据 流转 发 到 后 端的 容器 。 如 果 有 多 个 副本 ，kube-proxy 会 实 
现 负载 均衡 。 


3. Pod 网 络 


Pod 要 能 够 相互 通信 ，Kubernetes Cluster 必须 部 署 Pod 网 络 ，flannel 
是 其 中 一 个 可 选 方案 。 


43 ”完整 的 染 构 图 


flannel flannel 


enp0s8 p0s8 
192.168.56.106 (k8s-node1) 192.168.56.107 (k8s-node2) 





图 4-3 
你 可 能 会 问 : 为 什么 k8s-master 上 也 有 kubelet 和 kube-proxy 呢 ? 
这 是 因为 Master 上 也 可 以 运行 应 用 ， 即 Master 同 时 也 是 一 个 Node。 


几乎 所 有 的 Kubernetes 组 件 本 身 也 运行 在 Pod 里 ， 执 行 如 下 命令 ， 结 
果 如 图 4-4 所 示 。 


kubectl get pod --all-namespaces -o wide 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get pod --all-namespaces -o wide 
NAMESPACE 
kube-system 
kube-system 
kube-system 
kube-system 


kube-system 
kube-system 
kube-system 
kube-system 
kube-system 
kube-system 
kube-system 


NAME READY STATUS RESTARTS AGE IP 
etcd-k8s-master 1/1 Running 0 192.168.56.105 
kube-apiserver-k8s-master 1/1 Running 192.168.56.105 
kube-controller-manager-k8s-master 1/1 Running 192.168.56.105 
kube-dns-2425271678-123pv 3/3 Running 10.244.1.57 
kube-flannel-ds-cabpb 2/2 Running 192.168 .56.106 
kube-fLannel-ds-v@p3x 2/2 Running 192.168 .56.105 
kube-flannel-ds-xk49w 2/2 Running 192.168.56.107 
kube-proxy-16mg9 1/1 Running 192.168.56.106 
kube-proxy-wc430 1/1 Running 192.168.56.105 
kube-proxy-x15gd 1/1 Running 192.168.56.107 
kube-scheduler-k8s-master Running 192.168.56.105 


[222.2282 5-20 E 





ubuntu@k8s-master:~$ 


Kubernetes 的 系统 组 件 都 被 放 到 kube-system 


图 4-4 


一 个 kube-dns 组 件 ， 它 为 Cluster 提 供 DNS 服 务 ， 我 们 后 面 


kube-dns 是 在 执行 kubeadm init 时 (第 


NODE 
k8s-master 
k8s-master 
k8s-master 
k8s-nodei 
k8s-node1 
k8s-master 
k8s-node2 
k8s-node1 
k8s-master 
k8s-node2 
k8s-master 


namespace 中 。 这 里 有 
会 讨论 到 。 
E5) 作为 附加 组 件 安装 的 。 


kubelet 是 唯一 没有 以 容 右 形式 运行 的 Kubernetes 组 件 ， 它 在 Ubuntu 
中 通过 Systemd 服 务 运行 ， 如 图 4-5 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ sudo systemctl status kubelet.service 
.service - kubelet: The Kubernetes Node Agent 
: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled) 
: /etc/systemd/system/kubelet.service.d 


Active: 
Docs: 


Main PID: 
Tasks: 
Memory: 
CPU: 
CGroup: 


——10-kubeadm. conf 

active (running) since Wed 2017-08-23 11:01:08 HKT; 1 day 5h ago 
http://kubernetes.io/docs/ 

3946 (kubelet) 

19 

46.4M 

20min 29.149s 

/system.slice/kubelet.service 


I-3946 /usr/bin/kubelet --kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true 


——3974 journalctl -k -f 


图 4-5 





44 用 例子 把 它们 串 起 来 


为 了 帮助 大 家 更 好 地 理解 Kubernetes 架 构 ， 我 们 部 署 一 个 应 用 来 演 
示 各 个 组 件 之 间 是 如 何 协作 的 。 


执行 下 列 命令 ， 结 末 如 图 4-6 所 示 。 


kubectl run httpd-app --image-httpd --replicas-2 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl run httpd-app --image=httpd --replicas=2 


deployment “httpd-app" created 
ubuntu@k8s-master : ~$ 





图 4-6 
等 竺 一段 时 间 ， 应 用 部 署 完 成 ， 如 图 4-7 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get deployment 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
httpd-app 2 2 2 2 2m 
ubuntu@k8s-master : ~$ 





ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE IP NODE 
httpd-app-3211369089-9bgrz 1/1 Running 0 2m 10.244.1.58  k8s-node1 
httpd-app-3211369089-gn6z5 1/1 Running 0 2m 10.244.2.39 k&s-node2 





ubuntu@k8s-master : ~$ 


图 4-7 


Kubernetes 部 署 了 deployment httpd-app， 有 两 个 副本 Pod， 分 别 运行 
在 k8s-nodel 和 k8s-node2。 


详细 讨论 整个 部 署 过 程 ， 如 图 4-8 所 示 。 





© 9g deployment 
EB pod 
$ flannel 
ey ey 
@ @ 
C tei | 


flannel f flannel 


图 4-8 
(D kubect 发 送 部 署 请 求 到 API Server. 
(2) API Server 通 知 Controller Manager 创 建 一 个 deployment 资 源 。 


(3 Scheduler 执 行 调度 任务 ， 将 两 个 副本 Pod 分 发 到 k8s-node1 和 k8s- 
node2。 


(4) ”kk8s-nodel 和 k8s-node2 上 的 kubectl 在 各 自 的 节点 上 创建 并 运行 
Pod. 


补充 两 点 : 


(1) 应 用 的 配置 和 当前 状态 信息 保存 在 etcd 中 ， 执 行 kubectl get 
pod 时 API Server 会 从 etcd 中 读 取 这 些 数据 。 


(2) flannel 会 为 每 个 Pod 都 分 配 卫 。 因 为 没有 创建 service， 所 以 目 
前 kube-proxy 还 没 参与 进来 。 








45 ”小 结 


本 章 我 们 学 习 了 Kubernetes 的 架构 ， 讨 论 了 Master 和 Node 是 哪个 运 
行 的 组 件 和 服务 ， 并 通过 一 个 部 悍 案 例 加 深 了 对 架构 的 理解 。 


从 本 章 开始 ， 我 们 将 通过 实践 深入 学 习 Kubernetes 的 各 种 特性 。 作 
为 容器 编排 引擎 ， 最 重要 也 是 最 基本 的 功能 当然 是 运行 容器 化 应 用 ， 这 
就 是 本 章 的 内 容 。 





5.1 Deployment 


前 面 我 们 已 经 了 解 到 ，Kubernetes 通 过 各 种 Controller 来 管理 Pod 的 
生命 周期 。 为 了 满足 不 同业 务 场景 ，Kubernetes 开 发 了 Deployment、 
ReplicaSet、DaemonSet、StatefuleSet、Job 等 多 种 Controller。 我 们 首先 
学 习 最 常用 的 Deployment。 


5.1.1 运行 Deployment 


先 从 例子 开始 ， 运 行 一 个 Deployment: 


kubectl run nginx-deployment --image=nginx:1.7.9 --replicas-2 


Erf B a3 m d EL S PIT al AS Deployment nginx-deployment, 
容器 的 image 为 nginx:1.7.9。 


下 面 详细 分 析 Kubernetes 都 做 了 些 什么 工作 ， 如 图 5-1 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntuek8s-master:-$ kubectl run nginx-deployment --image-nginx:1.7.9 --replicas-2 
deployment "nginx-deployment" created 

ubuntu@k8s-master : ~$ 


ubuntu@k8s-master:~$ kubectl get deployment nginx-deployment 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
nginx-deployment 2 2 2 2 23s 





ubuntu@k8s-master:~$ 


图 5-1 


在 图 5-1 中 ， 通 过 kubectl get deployment 命 令 令 查 看 nginx-deployment 的 
状态 ， 输 出 显示 两 个 副本 正常 运行 。 


接 下 来 我 们 用 kubectl describe deployment 了 解 更 详细 的 信息 ， 如 图 
5-2 和 图 5-3 所 示 。 





DUNTUCKSS-master :~3 
ubuntuek8s-master:-$ kubectl describe deployment nginx-deployment 
$ nginx-deployment 

default 
Mon, 28 Aug 2017 10:28:32 +0800 
runsnginx-deployment 
deployment .kubernetes.io/revision=1 
run=nginx-depLoyment 
2 desired | 2 updated | 2 total | 2 available | 0 unavailable 
RollingUpdate 
0 


1 max unavailable, 1 max surge 


run=nginx-depLoyment 
Containers: 
nginx-deployment: 
Image: nginx:1.7.9 
Port: «none» 
Environment: «none» 
«none» 
«none» 


Status Reason 





大 部 分 内 容 都 是 自 解释 的 ， 我 们 重点 看 网 5-3。 这 里 告诉 我 们 创建 
了 一 个 ReplicaSet nginx-deployment-1260880958，Events 是 Deployment 的 
日 志 ， 记 录 了 ReplicaSet 的 启动 过 程 。 通 过 上 面 的 分 析 ， 也 验证 了 
Deployment 通 过 ReplicaSet 来 管理 Pod 的 事实 。 接 着 我 们 将 注意 力 切 换 到 
nginx-deployment-1260880958， 执 行 kubectl describe replicaset， 如 图 5-4 
所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl get replicaset 


NAME DESIRED CURRENT READY AGE 
nginx-deployment-1260880958 2 2 2 3m 


ubuntuek8s master : ~$ 





图 5-4 


两 个 副本 已 经 就 绕 ， 用 kubectl describe replicaset 查 看 详细 信息 ， 如 
图 5-5 和 图 5-6 所 示 。 





ubuntu@k&s-master : ~$ 

ubuntu@k8s-master:~$ kubectl describe replicaset nginx-deployment-1260880958 
nginx-deployment-1260880958 
default 
pod-tempLate-hash=1260880958 , run=nginx-depLoyment 
pod-template-hash-1260880958 
run=nginx-dep Loyment 
deployment .kubernetes.io/desired-replicas=2 
deployment .kubernetes .i0/max-replicas=3 
deployment .kubernetes . io/revision-1 
Deployment/nginx-deployment 
2 current / 2 desired 
2 Running / 0 Waiting / 0 Succeeded / 0 Failed 


Labels: pod-template-hash-1260880958 
run-nginx-deployment 

Containers: 

nginx-deployment: 

Image: nginx:1.7.9 

Port: <none> 

Environment: <none> 

Mounts: <none> 





图 5-5 
Message 


SuccessfulCreate Created pod: nginx- pete 1260880958-kn8w3 
SuccessfulCreate $ jdc 





Controlled By1RHH lE ReplicaSetzé H Deployment nginx-deployment&J 


建 的 。 图 5-6 是 两 个 副本 Pod 创 建 的 日 志 。 接 着 我 们 来 看 Pod， 执 行 
kubectl get pod, ir 图 5-7 所 示 。 





ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl get pod 
NAME READY STATUS RESTARTS AGE 


nginx-deployment-1260880958-kn8w3 1/1 Running 0 7m 
nginx-deployment-1260880958-rpjdc 1/1 Running 0 7m 
ubuntuék8s master: ~$ 





图 5-7 


个 副本 Pod 都 处 于 Running 状 态 ， 然 后 用 kubectl describe pod 查 看 
更 详细 的 信息 如 图 5-8 和 图 5-9 所 示 。 


ubuntuek8s-master:-$ kubectl describe pod nginx-deployment-1260880958-kn8w3 


Start Time: 
Labels: 


Annotations: 


ontainers: 


nginx-deployment-1260880958-kn8w3 

default 

k8s-node1/192.168.56.106 

Mon, 28 Aug 2017 10:28:32 «0800 

pod-template-hashs1260880958 

runenginx-deployment 
kubernetes.io/created-bys("kind":"SerializedReference" , "apiVersion":"v1", "reference" 


Running 
10.244.1.69 


nginx-deployment: 


Container ID: 


Image: 
Image ID: 
Port: 
State: 
Started: 
Ready: 


docker ://2653d5b3aa75c16632ac2e3fc0f d5411b194d9535d47c0c50f35913334b7e0d0b 
nginx:1.7.9 
docker-pullable://nginxesha256:e3456c851a152494c3e4f f 5f cc26f 240206abac0c9d794 
«none» 

Running 

Mon, 28 Aug 2017 10:28:33 «0800 

True 


Restart Count: 0 


Environment; 
Mounts: 


<none> 


/var/run/secrets/kubernetes, io/serviceaccount from default-token-slv6h (ro) 


Conditions: 
Type 
Initialized 
Ready 
PodScheduled 

Volumes: 
default-token- 

Type: 
SecretName: 
Optional: 

QoS Class: 


Status 
True 
True 
True 


siv6h; 

Secret (a volume populated by a Secret) 
default-token-s1v6h 

false 

BestEffort 


， «none» 


Normal 
Normal 
Normal 


Normal 
Normal 


Controlled 


Scheduled 


Successfully assigned nginx-deployment-1260880958-kn8w3 to k| 


SuccessfulMountVolume MountVolume.SetUp succeeded for volume "default-token-s1v6h" 


Pulled 
Created 
Started 


Container image "nginx:1.7.9" already present on machine 
Created container 
Started container 


图 5-9 





By 指明 此 Pod 是 由 ReplicaSet 


nginx-deployment- 


1260880958 创 建 的 。Events 记 录 了 Pod 的 启动 过 程 。 


WMR RER E 


如 image 不 存在 ) ， 也 能 在 这 里 查 到 原因 。 
总 结 一 下 这 个 过 程 中 ， 如 图 5-10 所 示 。 


nginx-deployment-1260880958 


© nginx-deployment 
| 


hi ea 
(1) 用 户 通 过 kubectl 创 建 Deployment。 
(2) Deployment 创 建 ReplicaSet。 
(3) ReplicaSet 创 建 Pod。 


从 图 5-10 也 可 以 看 出 ， 对 象 的 命名 方式 是 “ 子 对 象 的 名 字 = 父 对 象 名 
字 + 随 机 字符 串 或 数字 ”。 








5.1.2 ”命令 vs 配置 文件 


Kubernetes 文 持 两 种 创建 资源 的 方式 : 


(1) 用 kubectl 命 令 直 接 创建 ， 比 如 “kubectl run nginx-deployment -- 
image=nginx:1.7.9--replicas=2”， 在 命令 行 中 通过 参数 指定 资源 的 属性 。 


(2) 通过 配置 文件 和 kubectl apply 创 建 。 要 完成 前 面 同样 的 工作 ， 
可 执行 命令 “kubectl apply -f nginx.yml”，nginx.yml 的 内 容 如 图 5-11 所 
示 o 


apiVersion: extensions/vibetal 
kind: Deployment 
metadata: 

name: nginx-deployment 


metadata: 
labels: 
app: web_server 
spec: 
containers: 


- name: nginx 
image: nginx:1.7.9 


图 5-11 








资源 的 属性 写 在 配置 文件 中 ， 文 件 格式 为 YAML。 
下 面 对 这 两 种 方式 进行 比较 。 

(1) 基于 命令 的 方式 : 
e 简单、 直观 、 快 捷 ， 上 手 快 。 
适合 临时 测试 或 实验 。 


(2) 基于 配置 文件 的 方式 : 


配置 文件 描述 了 What， 即 应 用 最 终 要 达到 的 状态 。 
配置 文件 提供 了 创建 资源 的 模板 ， 能 够 重复 部 普 。 
可 以 像 管理 代码 一 样 管理 部 嗜 。 

适合 正式 的 、 路 环境 的 、 规 模 化 部 获 。 

这 种 方式 要 求 熟悉 配置 文件 的 语法 ， 有 一 定 难度 。 


后 面 我 们 都 将 采用 配置 文件 的 方式 ， 大 家 需要 尽快 熟悉 和 和 掌握。 
kubectl apply 不 但 能 够 创建 Kubernetes 资 源 ， 也 能 对 资源 进行 更 新 ， 


非常 方便 。 不 过 Kubernets 还 提供 了 几 个 类 似 的 命令 ， 例 如 kubect 
create. kubectl replace, kubectl edit 和 kubectl patch. 


为 避免 造成 不 必要 的 困扰 ， 我 们 会 尽量 只 使 用 kubectl apply， 此 命 
令 已 经 能 够 应 对 百 分 之 九 十 多 的 场景 ， 事 半 功 倍 。 








5.13 Deployment 配 置 文件 简介 


既然 要 用 YAML 配 置 文件 部 普 应 用 ， 现 在 就 很 有 必要 了 解 一 下 
Deployment 的 配置 格式 了 ， 其 他 Controller〈 比 如 DaemonSet) 非常 类 
似 。 


以 nginx-deployment 为 例 ， 配 置 文件 如 图 5-12 所 示 。 


apiVersion: extensions/vibetal (1 
kind: Deployment (2 
metadata: (3 
name: nginx-deployment 
spec: (4 z 
replicas: 5 
template: (6 
metadata: 5 
labels: < 


app: web_server 
spec: (8 
containers: 
- name: nginx 
image: nginx:1.7.9 





图 5-12 
(D apiVersion 是 当前 配置 格式 的 版 本 。 
(2) kind 是 要 创建 的 资源 类 型 ， 这 里 是 Deployment。 
(3) metadata 是 该 资源 的 元 数据 ，name 是 必需 的 元 数据 项 。 
(4) spec 部 分 是 该 Deployment 的 规格 说 明 。 
© replicas 指 明 副 本 数量 ， 默 认为 1。 
(6) template 定 义 Pod 的 模板 ， 这 是 配置 文件 的 重要 部 分 。 





@ metadata 定 义 Pod 的 元 数据 ， 至 少 要 定义 一 个 label。label 的 key 和 


value 可 以 任意 指定 。 
spec 描 述 Pod 的 规格 ， 此 部 分 定义 Pod 中 每 一 个 容 右 的 属性 ， 


name 和 image 是 必需 的 。 


此 nginx.yml 是 一 个 最 简单 的 Deployment 配 置 文件 ， 后 面 我 们 学 习 


Kubernetes 各 项 功能 时 会 逐步 丰富 这 个 文件 。 


执行 kubectl apply -fnginx.yml， 如 图 5-13 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ kubectl apply -f nginx. yml 


deployment "nginx-deployment" created 
ubuntu@k8s-master: ~$ 





图 5-13 


部 署 成 功 。 同 样 ， 也 可 以 通过 kubectl get 查 看 nginx-deployment 的 各 
种 资源 ， 如 图 5-14 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl get deployment 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
nginx-deployment 2 2 2 2 17s 
ubuntuék8s master: ~$ 
ubuntu@k8s-master:~$ kubectl get replicaset 
NAME DESIRED CURRENT READY AGE 
nginx-deployment-2721169382 2 2 2 29s 
ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get pod -o wide 
NAME READY STATUS RESTARTS AGE IP NODE 
nginx-deployment-2721169382-bl3cn 1/1 Running @ 41s 10.244.2.90 k8&s-node2 
nginx-deployment-2721169382-x6f3z 1/1 Running 0 41s 10.244.1.80 k8s-nodel 
ubuntuek8s-master:-$ 
图 5-14 





Deployment、ReplicaSet、Pod 都 已 经 就 绪 。 如 果 要 删除 这 些 资源 ， 
执行 kubectl delete deployment nginx-deployment 或 者 kubectl delete -f 
nginx.yml， 如 图 5-15 所 示 。 


ubuntuek8s-master : ~$ 
ubuntuék8s-master:-$ kubectl delete -f nginx.yml 


deployment "nginx-deployment" deleted 
ubuntu@k8s-master: ~$ 





图 5-15 


5.1.4 伸缩 


伸缩 是 指 在 线 增 加 或 减少 Pod 的 副本 数 。 


Deployment nginx-deployment 初 始 是 两 个 副本 ， 如 图 5-16 所 示 。 


ubuntuek8s master : ~$ 

ubuntuék8s-master:-$ kubectl apply -f nginx.yml 
deployment "nginx-deployment" created 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 


NAME READY STATUS RESTARTS 
nginx-deployment-2721169382-1gzzf 1/1 Running 0 
nginx-deployment-2721169382-pt53w 1/1 Running 0 
ubuntu@k8s-master:~$ 





图 5-16 


AGE IP 
8s 10.244.2.91 
8s 10.244.1.81 


NODE 
k8s-node2 


k8s-nodel 


k8s-nodel 和 k8s-node2 上 各 跑 了 一 个 副本 。 现 在 修改 nginx.yml 文 


件 ， 将 副本 改 成 5 个 ， 如 图 5-17 所 示 。 


apiVersion: extensions/vibetal 


kind: Deployment 
metadata: 
name: nginx-deployment 
spec: 
template: 
metadata: 
labels: 
app: web_server 
spec: 
containers: 
- name: nginx 
image: nginx:1.7.9 


图 5-17 


再 次 执行 kubectl apply， 如 图 5-18 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl apply -f nginx.yml 


ubuntuek8s-master:-$ kubectl get pod -o wide 
NAME READY STATUS RESTARTS 
0 


nginx-deployment-2721169382-gbjc2 1/1 Running 
nginx-deployment-2721169382-lgzzf 1/1 Running 
nginx-deployment-2721169382-mbrln 1/1 Running 
nginx-deployment-2721169382-pt53w 1/1 Running 
nginx-deployment-2721169382-s6hlx 1/1 Running 
ubuntu@k8s-master : ~$ 


图 5-18 





AGE IP 
10.244.2.93 
10.244.2.91 
10.244.2.92 
10.244.1.81 
10.244.1.82 


三 个 新 副本 被 创建 并 调度 到 k8s-node1 和 k8s-node2 E- 


出 于 安全 考虑 ， 默 认 配 置 下 Kubernetes 不 会 将 Pod 调 度 ur E 
点 。 如 果 和 希望 将 k8s-master 也 当 作 Node 使 用 ， 可 以 执行 如 下 命 


kubectl taint node k8s-master node-role.kubernetes.io/master- 


如 果 要 恢复 Master Only 状态， 执行 如 下 命令 : 


kubectl taint node 


k8s-master 


NODE 

k8s-node2 
k8s-node2 
k8s-node2 
k8s-node1 
k8s-node1 





node- 


role.kubernetes.io/masterz"":NoSchedule 





接 下 来 修改 配置 文件 ， 将 副本 数 减少 为 3 个 ， 重 新 执行 kubectl 


apply， 如 图 5-19 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl apply -f nginx.yml 
deployment "nginx-deployment" configured 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 
NAME READY 
nginx-deployment-2721169382-gbjc2 1/1 
nginx-deployment-2721169382-lgzzf 1/1 
nginx-deployment-2721169382-mbrln 0/1 
nginx-deployment-2721169382-pt53w 1/1 


STATUS RESTARTS AGE 


Running 0 14m 


Running 0 18m 
Terminating 0 14m 
Running 0 18m 


IP 
10.244.2.93 
10.244.2.91 
«none» 
10.244.1.81 


NODE 

k8s-node2 
k8s-node2 
k8s-node2 
k8s-node1 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 
NAME READY 
nginx-deployment-2721169382-gbjc2 1/1 
nginx-deployment-2721169382-lgzzf 1/1 
nginx-deployment-2721169382-pt53w 1/1 
ubuntu@k8s-master : ~$ 


STATUS 
Running 14m 
Running 18m 
Running 18m 


图 5-19 


最 终 保 留 了 3 个 副本 。 


RESTARTS AGE IP 

10.244.2.93 
10.244.2.91 
10.244.1.81 


NODE 

k8s-node2 
k8s-node2 
k8s-node1 








可 以 看 到 两 个 副本 被 删除 ， 


5.1.5 Failover 


下 面 我 们 模拟 k8s-node2 故 障 ， 关 财 该 节点 ， 如 图 5-20 所 示 。 


root@k8s-node2:~# halt -h 
Connection to 192.168.56.107 closed by remote host. 
Connection to 192.168.56.107 closed. 


图 5-20 





等 待 一 段 时 间 ，Kubernetes 会 检查 到 k8s-node2 不 可 用 ， 将 k8s-node2 
上 的 Pod 标 记 为 Unknown 状 态 ， 并 在 k8s-nodel1 上 新 创建 两 个 Pod， 维 持 
总 副本 数 为 3， 如 图 5-21 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ kubectl get node 
NAME STATUS AGE VERSION 
k8s-master Ready v1.7.4 

v1.7.4 

v1.7.4 
ubuntu@k8s-maste 
ubuntuék8s-master:-$ kubectl get pod -o wide 
NAME READY RESTARTS 
nginx-deployment-2721169382-gbjc2 1/1 0 
nginx-deployment-2721169382-lgzzf 1/1 
nginx-deployment-2721169382-p4mhr 1/1 
nginx-deployment-2721169382-pt53w 1/1 
nginx-deployment-2721169382-x8rtb 1/1 
ubuntu@k8s-master : ~$ 


0 
5 
Running 0 
Running 0 








当 k8s-node2 恢 复 后 ，Unknown 的 Pod 会 被 删除 ， 不 过 已 经 运行 的 
Pod 不 会 重新 调度 回 k8s-node2， 如 图 5-22 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl get node 
NAME STATUS AGE VERSION 
k8s-master Ready 6d v1.7.4 
k8s-node1 Ready 5d v1.7.4 


k8s-node2 Ready 5d v1.7.4 

ubuntu@k8s-master: ~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS IP 
nginx-deployment-2721169382-p4mhr 1/1 Running 1 12 10.244.1.87 
nginx-deployment-2721169382-pt53w 1/1 Running 1 10.244.1.85 
nginx-deployment-2721169382-x8rtb 1/1 Running al 10.244.1.88 
ubuntu@k8s-master: ~$ 





图 5-22 


删除 nginx-deployment， 如 图 5-23 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl delete deployment nginx-deployment 


deployment "nginx-deployment" deleted 
ubuntu@k8s-master:~$ 





图 5-23 


5.1.6 ”用 label 控 制 Pod 的 位 置 


默认 配置 下 ，Scheduler 会 将 Pod 调 度 到 所 有 可 用 的 Node。 不 过 有 些 
情况 我 们 希望 将 Pod 部 署 到 指定 的 Node， 比 如 将 有 大 量 磁 盘 IO 的 Pod 部 
或 者 Pod 需 要 GPU， 需 要 运行 在 配置 了 GPU 的 
"JE 


Kubernetes 是 通过 label 来 实现 这 个 功能 的 。 


label 是 key-value 对 ， 各 种 资源 都 可 以 设置 label， TI MN HE 
义 属 性 。 比 如 执行 如 下 命令 标注 k8s-node1 是 配置 了 SSD 的 节点 。 


kubectl label node k8s-nodei disktype=ssd 








然后 通过 kubectl get node --show-labels 查 看 节点 的 label， 如 图 5-24 所 
示 。 


node "k8s-nodel" labeled 
ubuntu@k8s-master: ~$ 
ubuntuék8s-master:-$ kubectl get node --show-labels 


NAME STATUS AGE VERSION LABELS 
k8s-master Ready 7d v1.7.4 beta.kubernetes.io/arch-amd64 ,beta.kubernetes.io/os-linux,kubernetes.io/hos 
k8s-node1 Ready 7d v1.7.4 ko bene os Ca acsi aue Sati cr E er 
k8s-node2 Ready 7d v1.7.4 beta.kubernetes.io/arch-amd64,beta.kubernetes.io/os-linux,kübernetes.10/hos 


ubuntu@k8s-master: ~$ 
图 5-24 





disktype=ssd 已 经 成 功 添加 到 k8s-nodel1， 除 了 disktype，Node 还 有 几 
个 Kubernetes 自 己 维护 的 label。 


有 了 disktype 这 个 自 定 义 label， 接 下 来 就 可 以 指定 将 Pod 部 署 到 k8s- 
nodel1。 编 辑 nginx.yml， 如 图 5-25 所 示 。 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 
name: nginx-deployment 
spec: 
replicas: 
template: 
metadata: 
labels: 
app: web_server 
spec: 
containers: 
- name: nginx 
image: ngi 
nodeSelector: 
disktype: ssd 





图 5-25 


在 Pod 模 板 的 spec 里 通过 nodeSelector 指 定 将 此 Pod 部 署 到 具有 label 
disktype=ssd 的 Node 上。 


部 晋 Deployment 并 得 看 Pod 的 运行 节点 ， 如 图 5-26 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl apply -f nginx.yml 

deployment "nginx-deployment" created 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS IP 
nginx-deployment-204403116-1kk23 1/1 Running 0 10.244.1.97 
nginx-deployment-204403116-gcnkz 1/1 Running 10.244.1.101 
nginx-deployment-204403116-kmbwr 1/1 Running 10.244.1.96 
nginx-deployment-204403116-kzpnf 1/1 Running 10.244.1.100 


nginx-deployment-204403116-vbz47 1/1 Running 10.244.1.98 
nginx-deployment-204403116-vvh54 1/1 Running 10.244.1.99 
ubuntu@k8s-master : ~$ 





图 5-26 


全 部 6 个 副本 都 运行 在 k8s-nodel1 上 ， 符 合 我 们 的 预期 。 要 删除 label 
disktype， 执 行 如 下 命令 : 


kubectl label node k8s-node1 disktype- 


- 即 删 除 ， 如 图 5-27 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl label node k8s-nodel disktype- 
node "k8s-node: labeled 

lubuntu@k8s-master:~$ 

lubuntu@k8s-master:~$ kubectl get node --show-labels 


NAME STATUS AGE VERSION LABELS 


k8s-master Ready 8d v1.7.4  beta.kubernetes.io/arch-and64, beta. kubernetes. io/0s-linux, kubernetes . io/hostname=k8s-master ,node-role. kubernetes . io/master: 


k8s-nodel Ready 7d v1.7.4 ^ beta.kubernetes.io/arch-and64, beta. kubernetes. 


ubuntuek8s master :~$ 


图 5-27 


nux, kubernetes . io/hostname-k8s-nodel 
Ready 7d v1.7.4  beta.kubernetes.io/arch-and64 , beta. kubernetes. io/os-linux, kubernetes . io/hostname-k8s-node2 





ANIL UCI Pod3fA4^ zs SUBE. MKI Ek8s-node1 上 运行 ， 如 图 5-28 


所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS 
nginx-deployment-204403116-1kk23 1/1 Running 
nginx-deployment-204403116-gcnkz 1/1 Running 
nginx-deployment-204403116-kmbwr 1/4 Running 
nginx-deployment-204403116-kzpnf 1/1 Running 
nginx-deployment-204403116-vbz47 1/1 Running 
nginx-deployment-204403116-vvh54 1/1 Running 
ubuntu@k8s-master:~$ 


图 5-28 


RESTARTS 





除非 在 nginx.yml 中 删除 nodeSelector 设 置 ， 然 后 通过 kubectl 


新 部 署 ， 如 图 5-29 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f nginx.yml 
deployment "nginx-deployment" configured 
ubuntu@k8s-master : ~$ 

ubuntu@k&8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS 
nginx-deployment-204403116-1kk23 0/1 Terminating 
nginx-deployment-204403116-kmbwr 1/1 Terminating 
nginx-deployment-204403116-kzpnf 0/1 Terminating 
nginx-deployment-204403116-vbz47 0/1 Terminating 
nginx-deployment-204403116-vvh54 0/1 Terminating 
nginx-deployment-2721169382-56mhh 1/1 Running 
nginx-deployment-2721169382-bfOrd 1/1 Running 
nginx-deployment-2721169382-cnh8b 1/1 Running 
nginx-deployment-2721169382-1qhn6 1/1 Running 
nginx-deployment-2721169382-q61jr 1/1 Running 
nginx-deployment-2721169382-r9831 TA Running 


ubuntuek8s-master:-$ 
图 5-29 


Kubernetes 会 删除 之 前 的 Pod 并 调度 和 运行 新 的 Pod。 


RESTARTS 


[SM EE 


IP 
«none» 


10.244. 


«none» 
«none» 
«none» 


10.244. 
10.244. 
10.244. 
10.244. 
10.244. 
10.244. 


NODE 

k8s-node1 
k8s-node1 
k8s-node1 
k8s-node1 
k8s-node1 
k8s-node2 
k8s-node2 
k8s-node2 
k8s-node2 
k8s-node1 
k8s-node2 





apply È. 


5.2 DaemonSet 


Deployment? # A) fill Jk Pod 4) B 7E 4 Node E, fj^ *Nodeiliu] Be 
运行 好 几 个 副本 。DaemonSet 的 不 同 之 处 在 于 : 每 个 Node 上 最 多 只 能 运 
行 一 个 副本 。 

DaemonSet 的 典型 应 用 场景 

(1) 在 集群 的 每 个 节点 上 运行 存储 Daemon， 比 如 glusterd 或 ceph。 


(2) 在 每 个 节点 上 运行 日 志 收 集 Daemon， 比 如 flunentd 或 
logstash. 





(3) 在 每 个 节点 上 运行 监控 Daemon， 比 如 Prometheus Node 
Exporter 或 collectd。 


其 实 Kubernetes 自 己 就 在 用 DaemonSet 运 行 系统 组 件 。 执 行 如 下 命 
如 图 5-30 所 示 。 


kubectl get daemonset --namespace=kube-system 


ubuntu@k8s-master : ~$ 


ubuntuék8s-master:-$ kubectl get daemonset --namespace-kube-system 

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE-SELECTOR 
kube-flannel-ds 3 3 3 3 5) beta.kubernetes.io/arch-a 
kube-proxy 3 sj <none> 
ubuntu@k8s-master : ~$ 





图 5-30 


DaemonSet kube-flannel-ds 和 kube-proxy 分 别 负 责 在 每 个 节点 上 运行 
flannel 和 kube-proxy 组 件 ， 如 图 5-31 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get pod --namespace-kube-system -o wide 

NAME READY STATUS RESTARTS 

etcd-k8s-master 1/1 Running 192.168.56.105 k&s-master 
kube-apiserver-k8s-master 1/1 Running 192.168.56.105 k8s-master 
kube-controller-manager-k8s-master 1/1 Running 192.168.56.105 k8&s-master 
kube-dns-2425271678-51xc4 3/3 ing 10.244 .1.89 k8s-node1 
ube-flannel-ds-cqbpb f, Running 1 192.168.56.106 Kk8s-nodel 


kube-flannel-ds-v0p3x Running 192.168.56.105 — k8s-master 

kube-flannel-ds-xk49w Running 192.168.56.107 k8&s-node2 

kube-proxy-16mg9 Running 192.168.56.106 — k8s-nodei 

kube-proxy-wc4j0 Running 192.168.56.105 k8&s-master 

kube- sch xl5gd Running 192.168.56.107 k8s-node2 
OS -Ma Run 8d 92.168.506. 10 3 


ibuntuPkdis- master: ~$ 





为 flannel 和 kube-proxy 属 于 系统 组 件 ， 需 要 在 命令 行 中 通过 -- 
namespace=kube-system 指 定 namespace kube-system。 若 不 指定 ， 则 只 返 
回 默认 namespace default 中 的 资源 。 


5.2.1 kube-flannel-ds 


下 面 我 们 通过 分 析 kube-flannel-ds 来 学 习 DaemonSet。 


还 记得 之 前 是 如 何 部 署 fannel 网 络 的 吗 ? 我 们 执行 了 如 下 命令 : 


kubectl apply - 
f https://raw.githubusercontent.com/coreos/flannel/master/Documen 
flannel.yml 


flannel 的 DaemonSet 就 定义 在 kube-flannel.yml 中 ， 如 图 5-32 所 示 。 


apiVersion: extensions/vibetal 
kind: DaemonSet (1 
metadata: 
name: kube-flannel-ds 
namespace: kube-system 
labels: 
tier: node 
app: flannel 
spec: 
template: 
metadata: 
labels: 
tier: node 


app: flannel 


spec: 

hostNetwork: 2 

nodeSelector: 
beta. kubernetes.io/arch: amd64 

containers: (3 

- name: kube-flannel 
image: quay.io/coreos/flannel:v0.8.0-amd64 
command: [ 

- name: install-cni 
image: quay.io/coreos/flannel:v0.8.0-amd64 
command: [ 





图 5-32 


TER: 配置 文件 的 完整 内 容 要 更 复杂 一 些 ， 为 了 更 好 地 学 习 
DaemonSet， 这 里 只 保留 了 最 重要 的 内 容 。 


(D DaemonSet 配 置 文件 的 语法 和 结构 与 Deployment 几 乎 完全 一 样 ， 








只 是 将 kind 设 为 DaemonSet。 

(2 hostName 指 定 Pod 直 接 使 用 的 是 Node 网 络 ， 相 当 于 docker run -- 
network=host。 考 虑 到 flannel 需 要 为 集群 提供 网 络 连接 ， 这 个 要 求 是 合 
理 的 。 

(8 containers 定 义 了 运行 flannel 服 务 的 两 个 容器 。 


下 面 我 们 再 来 分 析 另 一 个 DaemonSet: kube-proxy。 


5.2.2 kube-proxy 





由 于 无 法 拿 到 kube-proxy 的 YAML 文 件 ， 只 能 运行 如 下 命令 查看 配 


kubectl edit daemonset kube-proxy --namespace-kube-system 


结果 如 图 5-33 所 示 。 


apiVersion: extensions/vibetal 
kind: DaemonSet (1 
metadata: 
labels: 
k8s-app: kube-proxy 
name: kube-proxy 
namespace: kube-system 
spec: 
selector: 
matchLabels: 
k8s-app: kube-proxy 
template: 
metadata: 
labels: 
k8s-app: kube-proxy 
spec: 
containers: 
- command: 
- /usr/local/bin/kube-proxy 
- --kubeconfigz-/var/lib/kube-proxy/kubeconfig.conf 
- --cluster-cidr-10.244.0.0/16 
image: gcr.io/google. containers/kube-proxy-amd64:v1.7.4 
name: kube-proxy 
status: (3 
currentNumberScheduled: 
desiredNumberScheduled: 
numberAvai lable: 
numberMisscheduled: 
numberReady : 
observedGeneration: 
updatedNumberScheduled: 





图 5-33 
同样 为 了 便于 理解 ， 这 里 只 保留 了 最 重要 的 信息 。 
(D kind: DaemonSet 指 定 这 是 一 个 DaemonSet 类 型 的 资源 。 


(2) containers 定 义 了 kube-proxy 的 容器 。 





(3) status 是 当前 DaemonSet 的 运行 时 状态 ， 这 个 部 分 是 kubectl edit 特 
有 的 。 其 实 Kubernetes 集 群 中 每 个 当前 运行 的 资源 都 可 以 通过 kubectl 
edit 查 看 其 配置 和 运行 状态 ， 比 如 kubectl edit ^ deployment nginx- 
deployment。 


5.2.3 ”运行 自己 的 DaemonSet 


本 小 节 以 Prometheus Node Exporter 为 例 演示 用 户 如 何 运 行 自己 的 


DaemonSet. 


Prometheus 是 流行 的 系统 监控 方案 ，Node Exporterz Prometheus} 
agent， 以 Daemon 的 形式 运行 在 每 个 被 监控 节点 上 。 


如 果 是 直接 在 Docker 中 运行 Node Exporter 容 器 ， 命 令 为 : 


docker run -d \ 

-v "/proc:/host/proc" \ 

-v "/sys:/host/sys" \ 

-v "/:/rootfs" \ 

--net=host \ 

prom/node-exporter \ 

--path.procfs /host/proc \ 

--path.sysfs /host/sys \ 

--collector.filesystem.ignored-mount- 

points "^/(sys|proc|dev|host|etc)($]|/)" 


将 其 转换 为 DaemonSet 的 YAML 配 置 文件 node_exporter.yml， 如 图 5- 
34 所 示 。 


lapiVersion: extensions/vibetal 
kind: DaemonSet 
metadata: 
name; node-exporter-daemonset 
spec: 
template: 
metadata: 
Labels: 
app: prometheus 
spec: 
hostNetwork: 
containers: 
- name: node-exporter 
image: prom/node-exporter 
imagePullPolicy: IfNotPresent 
command: 2 
/bin/node. exporter 
--path.procfs 
/host/proc 
--path.sysfs 


/host/sys 
- --collector.filesystem.ignored-mount-points 
- A/Csys|procidevilhostletc)($1/) 


voLlumeMounts: 
- name: proc 
mountPath: /host/proc 
name: sys 
mountPath: /host/sys 
- name: root 
mountPath: /rootfs 
volumes: 
- name: proc 
hostPath: 
path: /proc 
- name: sys 
hostPath: 
path: /sys 
- name: root 
hostPath: 
path: / 





图 5-34 


CO 直接 使 用 Host 的 网 络 。 
D 设置 容器 启动 命令 。 


@ ”通过 Volume 将 Host 路 径 /proc、/sys 和 /映射 到 容器 中 。 我 们 将 在 
后 面 详细 讨论 Volume。 


执行 kubectl apply -f node_exporter.yml， 如 图 5-35 所 示 。 





ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl apply -f node_exporter.yml 
daemonset "node-exporter-daemonset" created 

ubuntuék8s master: ~$ 


ubuntuék8s-master:-$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE IP NODE 
node-exporter-daemonset-b2w@x 1/1 Running 0 192.168.56.107 k8&s-node2 
node-exporter-daemonset-kvmkr 1/1 Running 0 192.168.56.106 ^ k8s-nodel 
ubuntu@k8s-master : ~$ 





图 5-35 


DaemonSet node-exporter-daemonset 部 署 成 功 ，k8s-node1 和 Kk8s- 
node2 上 分 别 运行 了 一 个 node exporter Pod. 


5.3 Job 





容器 按照 持续 运行 的 时 间 可 分 为 两 类 : 服务 类 容器 和 工作 类 容器 。 

服务 类 容器 通常 持续 提供 服务 ， 需 要 一 直 运 行 ， 比 如 HTTP 
Server、Daemon 等 。 工 作 类 容器 则 是 一 次 性 任务 ， 比 如 批 处理 程 序 ， 完 
成 后 容器 就 退出 。 


Kubernetes 的 Deployment、ReplicaSet 和 DaemonSet 都 用 于 管理 服务 
类 容器 ;对 于 工作 类 容器 ， 我 们 使 用 Job。 


先 看 一 个 简单 的 Job 配 置 文件 myjob.yml， 如 图 5-36 所 示 。 


apiVersion: batch/v1 (1 
kind: Job (2 


name: myjob 
spec: 
template: 
metadata: 
name: myjob 
spec: 

containers: 

- name: hello 
image: busybox 
command: [ , 

restartPolicy: Never (3) 





图 5-36 
(D batch/v1 是 当前 Job 的 apiVersion 。 
(2) 指明 当前 资源 的 类 型 为 Job。 
(3) restartPolicy 指 定 什么 情况 下 需要 重启 容器 。 对 于 Job， 只 能 设置 


为 Never 或 者 OnFailure。 对 于 其 他 controller〈 比 如 Deployment) ， 可 以 
设置 为 Always。 





通过 kubectl apply -f myjob.yml 启 动 Job， 如 图 5-37 所 示 。 


ubuntuék8s master : ~$ 
ubuntuék8s-master:-$ kubectl apply -f myjob.yml 


job "myjob" created 
ubuntu@k8s-master: ~$ 





图 5-37 


通过 kubectl get job 查看 Job 的 状态 ， 如 图 5-38 所 示 。 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ kubectl get job 
NAME DESIRED SUCCESSFUL AGE 
my job 1 1 12s 
ubuntu@k8s-master: ~$ 

图 5-38 





DESIRED 和 SUCCESSFUL 都 为 1， 表 示 按 照 预期 启动 了 一 个 Pod， 
并 且 已 经 成 功 执行 。 通 过 kubectl get ”pod 查看 Pod 的 状态 ， 如 图 5-39 所 
ZN o 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod 

No resources found, use --show-all to see completed objects. 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod --show-all 

NAME READY STATUS RESTARTS 

myjob-nfkxk X 0/1 Completed 0 

ubuntu@k8s-master : ~$ 





图 5-39 


因为 Pod 执 行 完毕 后 容器 已 经 退出 ， 需 要 用 --show-all 才 能 查看 
Completed 状 态 的 Pod。 


通过 kubectl logs 可 以 查看 Pod 的 标准 输出 ， 如 图 5-40 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k&s-master:~$ kubectl logs myjob-nfkxk 


hello k8s job! 
ubuntu@k8s-master: ~$ 





图 5-40 


5.3.1 Pod 失 败 的 情况 


以 上 是 Pod 成 功 执行 的 情况 ， 如 果 Pod 失 败 了 会 怎么 样 呢 ? 


我 们 做 个 试验 ， 修 改 myjob.yml， 故 意 引 入 一 个 错误 ， 如 图 5-41 所 











Ze 
apiVersion: batch/v1 
kind: Job 
metadata: 
name: myjob 
spec: 
template: 
metadata: 
name: myjob 
spec: 
containers: 
- name: hello 
i e: bu 
图 5-41 
ZA 3 -Aka 三 二 
先 删 除 之 前 的 Job， 如 图 5-42 所 示 。 
ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl delete -f myjob.yml 
job "myjob" deleted 
ubuntu@k8s-master: ~$ 
图 5-42 
\ 一 /一 y NE = 
运行 新 的 Job 并 碍 看 状态 ， 如 图 5-43 所 示 。 
ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl apply -f myjob.yml 
job "myjob" created 
ubuntuék8s -master : ~$ 
ubuntuék8s-master:-$ kubectl get job 
NAME DESIRED SUCCESSFUL AGE 
myjob 1 0 7s 
ubuntu@k8s-master :~$ 
图 5-43 
N mS Y P yz, JE, v VELIS 
当前 SUCCESSFUL 的 Pod 数 量 为 0， 查 看 Pod 的 状态 ， 如 图 5-44 所 
ZN o 


NAME STATUS RESTARTS AGE 

my job-0x0z0 ContainerCannotRun 11s 
ContainerCannotRun 9s 
ContainerCannotRun 6s 
ContainerCannotRun 14s 
ContainerCannotRun 4s 
ContainerCreating 1s 


ubuntuék8s-master : ~$ 





图 5-44 


可 以 看 到 有 多 个 Pod， 状 态 均 不 正常 。 通 过 kubectl describe pod £t Zi 
某 个 Pod 的 启动 日 志 ， 如 图 5-45 所 示 。 


k8s-node2 
lume "default-token-k87vh" 











日 志 显 示 没 有 可 执行 程序 ， 符 合 我 们 的 预期 。 


下 面 解释 一 个 现象 : 为 什么 kubectl get pod 会 看 到 这 么 多 个 失败 的 
Pod? 


原因 是 : 当 第 一 个 Pod 局 动 时 ， 容 器 失败 退出 ， 根 据 restartPolicy: 
Never， 此 失败 容器 不 会 被 重启 ， 但 Job DESIRED 的 Pod 是 1， 目 前 
SUCCESSFUL 为 0， 不 满足 ， 所 以 Job ”controller 会 启动 新 的 Pod， 直 到 
SUCCESSFUL 为 1。 对 于 我 们 这 个 例子 ，SUCCESSFUL 永 远 也 到 不 了 
1， 所 以 Job ”controller 会 一 直 创 建新 的 Pod。 为 了 终止 这 个 行为 ， 只 能 删 
除 Job， 如 图 5-46 所 示 。 





ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl delete -f myjob.yml 


job "myjob" deleted 
ubuntu@k8s-master: ~$ 





图 5-46 


如 果 将 restartPolicy 设 置 为 OnFailure 会 怎么 样 ? 下 面 我 们 实践 一 下 ， 
修改 myjob.yml 后 重新 局 动 ， 如 图 5-47 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f myjob.yml 
job "myjob" created 

ubuntuék8s master : ~$ 


ubuntuék8s-master:-$ kubectl get job 
NAME DESIRED SUCCESSFUL AGE 
myjob 1 0 5s 
ubuntuék8s master : ~$ 





图 5-47 


Job 的 SUCCESSFUL “Pod 数 量 还 是 0， 再 看 看 Pod 的 情况 ， 如 图 5-48 
所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get pod --show-all 
NAME 


READY 
myjob-831x0 0/1 
ubuntu@k8s-master : ~$ 


STATUS 


图 5-48 


CrashLoopBackOff 


RESTARTS AGE 
3 1m 





这 里 只 有 一 个 Pod， 不 过 RESTARTS 为 3， 而 且 不 断 增 加 ， 说 明 


OnFailure 生 效 ， 容 器 失败 后 会 目 动 重启 。 


5.3.2 Job 的 并 行 性 


有 时 我 们 希望 能 同时 运行 多 个 Pod， 提 高 Job 的 执行 效率 。 这 个 可 以 


通过 parallelism 设 置 ， 如 图 5-49 所 示 。 


apiVersion: batch/v1 
kind: Job 
metadata: 

name: myjob 


spec: 
parallelism: 
template: 


metadata: 
name: myjob 
spec: 
containers: 
- name: hello 
image: busybox 
command: [ A 
restartPolicy: OnFailure 


图 5-49 


这 里 我 们 将 并 行 的 Pod 数 量 设置 为 2， 





实践 一 下 ， 如 图 5-50 所 示 。 





Job 一 共 启 动 了 两 个 Pod， 而 且 AGE 相 同 ， 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f myjob.yml 
job "myjob" created 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get job 

NAME DESIRED SUCCESSFUL AGE 

myjob <none> 2 6s 

ubuntuék8s -master ; ~$ 


可 见 是 并 行 运行 的 。 


ubuntuék8s-master:-$ kubectl get pod --show-all -o wide 


NAME 
myjob-cn4zs 0/1 
myjob-vhpzs Q/1 
ubuntu@k8s-master : ~$ 


READY STATUS 


图 5-50 


RESTARTS AGE 
Completed 0 12s 
Completed 0 12s 





IP NODE 
10.244.2.5 k8s-node2 
10.244.1.28 k8s-node1 


我 们 还 可 以 通过 completions 设 置 Job 成 功 完 成 Pod 的 总 数 ， 如 图 5-51 
所 示 。 


apiVersion: batch/v1 
kind: Job 
metadata: 
name: myjob 
spec: 
completions: 
parallelism: 
template: 
metadata: 
name: myjob 
spec: 

containers: 

- name: hello 
image: busybox 
command: [ ; 

restartPolicy: OnFailure 


图 5-51 


上 面 配置 的 含义 是 : 每 次 运行 两 个 pod， 直 到 总 共有 6 个 Pod 成 功 完 
成 。 实 践 一 下 ， 如 图 5-52 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl apply -f myjob.yml 
job "myjob" created 
ubuntuék8s-master : ~$ 


ubuntu@k8s-master:~$ kubectl get job 
NAME DESIRED SUCCESSFUL AGE 
myjob 6 6 9s 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get pod --show-all -o wide 

NAME READY STATUS RESTARTS AGE IP NODE 
myjob-Ot4zk 0/1 Completed 0 16s 10.244.2.6 k8s-node2 
myjob-79xkx  Q/1 Completed 11s 10.244.2.8 k8s-node2 
myjob-p421x 0/1 Completed 14s 10.244.1.30 — k8s-nodei 
myjob-rfvd7 0/1 Completed 13s 10.244.2.7 k8s-node2 
myjob-srpg9 0/1 Completed 12s 10.244.1.31  k8s-nodel 
myjob-wl8tt 0/1 Completed 16s 10.244.1.29  k8s-nodel 
ubuntu@k8s-master:~$ 











图 5-52 


DESIRED 和 SUCCESSFUL 均 为 6， 符 合 预 期 。 如 果 不 指定 
completions/lparallelism, EA [35 731. 


上 面 的 例子 只 是 为 了 演示 Job 的 并 行 特性 ， 实 际 用 途 不 大 。 不 过 现 
实 中 确实 存在 很 多 需要 并 行 处 理 的 场景 。 比 如 批 处 理 程序 ， 每 个 副本 
(Pod) 都 会 从 任务 池 中 读 取 任务 并 执行 ， 副 本 越 多 ， 执 行 时 间 就 越 
短 ， 效 率 就 越 高 。 这 种 类 似 的 场景 都 可 以 用 Job 来 实现 。 














5.3.3 ”定时 Job 


Linux 中 有 cron 程 序 定时 执行 任务 ，Kubemetes 的 CronJob 提 供 了 类 似 
的 功能 ， 可 以 定时 执行 Job。CronJob 配 置 文件 示例 如 图 5-53 所 示 。 


apiVersion: batch/v2alphal (1) 
kind: CronJob (2 
metadata: 

name: hello 


spec: 
schedule: 
jobTemplate: (4 
spec: 


template: 
spec: 
containers: 
- name: hello 
image: busybox 
command: [ 3 
restartPolicy: OnFailure 


图 5-53 





(D batch/v2alphal 是 当前 CronJob 的 apiVersion。 
(2) 指明 当前 资源 的 类 型 为 CronJob。 


(3) schedule 指 定 什么 时 候 运 行 Job， 其 格式 与 Linux cron 一 致 。 这 里 
#/1 六 六 六 的 含义 是 每 一 分 钟 启动 一 次 。 


(4) jobTemplate 定 义 Job 的 模板 ， 格 式 与 前 面 的 Job 一 致 。 
接 下 来 通过 kubectl apply 创 建 CronJob， 如 图 5-54 所 示 。 


ubuntuék8s master : ~$ 
ubuntu@k8s-master:~$ kubectl apply -f cronjob.yml 


error: error validating "cronjob.yml": error validating data: the server could not find th 
resource; if you choose to ignore these errors, turn validation off with --validate-false 
ubuntu@k8s-master : ~$ 





图 5-54 


失败 了 。 这 是 因为 Kubernetes 默 认 没 有 enable CronJob 功 能 ， 需 要 在 
kube-apiserver 中 加 入 这 个 功能 。 方 法 很 简单 ， 修 改 kube-apiserver 的 配置 
文件 /etc/kubernetes/manifests/kubeapiserver.yaml， 如 图 5-55 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 
annotations: 
scheduler.alpha.kubernetes.io/critical-pod: 
creationTimestamp: 
Labels: 
component: kube-apiserver 
tier: control-plane 
name: kube-apiserver 
namespace: kube-system 
spec: 
containers: 
- command: 


--runtime-config 

--requestheader-group-headers-X-Remote-Group 
--requestheader-extra-headers-prefix=X-Remote-Extra- 
--requestheader-allowed-names=front-proxy-cLlient 
--kubelet-client-key-/etc/kubernetes/pki/apiserver-kubelet-clieni 
--kubelet-preferred-address-types-InternalIP,ExternalIP,Hostname 
--allow-privileged- 

--experimental-bootstrap-token-auth- 
--requestheader-username-headers=X-Remote-User 
--service-account-key-file=/etc/kubernetes/pki/sa. pub 


图 5-55 


kube-apiserver 本 身 也 是 一 个 Pod， 在 启动 参数 中 加 上 --runtime- 
config=batch/v2alphal=true 妈 可。 然后 重启 kubelet 服 务 : 





systemctl restart kubelet.service 


kubeletZ: Œ Hi kube-apiserver Pod. iii kubectl api-versionst t kube- 
apiserver 现 在 已 经 支持 batch/v2alphal， 如 图 5-56 所 示 。 


ubuntu@k8s-master:~$ kubectl api-versions 
apiextensions.k8s.io/vibetal 
apiregistration.k8s.io/vibetai1 
apps/v1beta1 

authentication. k8s.io/v1 
authentication .k8s.io/v1beta1 
authorization.k8s.io/v1 
authorization. k8&s.io/vibetal 
autoscaling/v1 

batch/v1 
certificates.k8s.10/vibetal 
extensions/vibetal 

networking. k8s.i0/v1 
poLlicy/vibetal 

rbac. authorization. k8s.i10/vialphai 
rbac.authorization.k8&s.io0/vibetal 
settings.k8s.io/vialphai 
storage.k8s.io/v1 
storage.k&s.10/vibetal 

v1 

ubuntuek8s-master : ~$ 


图 5-56 


再 次 创建 CronJob， 如 图 5-57 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f cronjob.yml 
cronjob "hello" created 

ubuntu@k8s-master : ~$ 








图 5-57 


这 次 成 功 了 。 通 过 kubectl get cronjob 查 看 CronJob 的 状态 ， 如 图 5-58 
所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get cronjob 
NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE 


hello eR SA AES False 0 Tue, 12 Sep 2017 10:21:00 +0800 
ubuntu@k8s-master : ~$ 





图 5-58 


等 待 几 分 钟 ， 然 后 通过 kubectl get jobs 查 看 Job 的 执行 情况 ， 如 图 5- 


ubuntuek8s master: ~$ 
ubuntu@k8s-master:~$ kubectl get jobs 
NAME DESIRED SUCCESSFUL 
hello-1505181600 1 T 
hello-1505181660 


1 
hello-1505181720 T 
hello-1505181780 1 
hello-1505181840 1 
hello-1505181900 1 
ubuntu@k8s-master: ~$ 


图 5-59 


可 以 看 到 每 隔 一 分 钟 就 会 情 动 一 个 Job。 执 行 kubectl 


个 Job 的 运行 日 志 ， 如 图 5-60 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get pod --show-all 

NAME READY STATUS RESTARTS 
hello-1505181600-Ohrx5 0/1 Completed 0 
hello-1505181660-nbgwd 0/1 Completed 
hello-1505181720-1f350 0/1 Completed 
hello-1505181780-tjhq2 0/1 Completed 


hello-1505181840-lqdbv 0/1 Completed 
hello-1505181900-ggfr2 Q/1 Completed 
ubuntu@k&8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl logs hello-1505181720-1f350 
hello k8s job! 

ubuntu@k8s-master : ~$ 


图 5-60 





AGE 
5m 
4m 
3m 
2m 
1m 
10s 





logs 可 得 看 某 


5.4 小结 


运行 容器 化 应 用 是 Kubernetes 最 重要 的 核心 功能 。 为 满足 不 同 的 业 
务 需 要 ，Kubermnetes 提 供 了 多 种 Controller， 包 括 Deployment、 
DaemonSet、Job、CronJob 等 。 本 章 我 们 通过 实践 详细 学 习 了 这 些 
Controller， 并 讨论 了 它们 的 特性 和 应 用 场景 。 


第 6 章 ” 通 过 Service 访 问 Pod 


我 们 不 应 该 期 望 Kubernetes Pod 是 健壮 的 ， 而 是 要 假设 Pod 中 的 容器 
很 可 能 因为 各 种 原因 发 生 故 障 而 死 掉 。Deployment 等 Controller 会 通过 动 
态 创 建 和 销毁 Pod 来 保证 应 用 整体 的 健壮 性 。 换 名 话说 ，Pod 是 脆弱 的 ， 
但 应 用 是 健壮 的 。 


每 个 Pod 都 有 自己 的 卫 地 址 。 当 Controller 用 新 Pod 蔡 代 发 生 故 障 的 
Pod 时 ， 新 Pod 会 分 配 到 新 的 IP 地 址 。 这 样 就 产生 了 一 个 问题 : 


如 果 一 组 Pod 对 外 提供 服务 〈 比 如 HTTP) ， 它 们 的 IP 很 有 可 能 发 生 
变化 ， 那 么 客户 端 如 何 找到 并 访问 这 个 服务 呢 ? 


Kubernetes 给 出 的 解决 方案 是 Service。 


6.1 8| Æ Service 


Kubernetes Service 从 逻辑 上 代表 了 一 组 Pod， 具 体 是 哪些 Pod 则 是 由 
label 来 挑选 的 。Service 有 自己 的 PP， 而 且 这 个 IP 是 不 变 的 。 客 户 端 只 需 
要 访问 Service 的 IP，Kubernetes 则 负责 建立 和 维护 Service 与 Pod 的 映射 关 
Du HRS 对 客户 端 不 会 有 任何 影响 ， 因 为 Service 没 


来 看 个 例子 ， 创 建 下 面 的 这 个 Deployment， 如 图 6-1 所 示 。 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 

name: httpd 
spec: 

replicas: 

template: 

metadata: 


labels: 
run: httpd 


spec: 
containers: 

- name: httpd 
image: httpd 
ports: 

- containerPort: 


图 6-1 





我 们 启动 了 三 个 Pod， 运 行 httpd 镜 像 ，label 是 run: httpd，Service 将 
会 用 这 个 label 来 挑选 Pod， 如 图 6-2 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f httpd.yml 

deployment "httpd" created 

ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS NODE 
httpd-741508562-192vp 1/1 Running 0 .4. k8s-node1 


httpd-741508562-6g4fc 1/1 Running 0 .4. k8s-node1 
httpd-741508562-6hh9g 1/1 Running 8 Js k8s-node2 
ubuntu@k8s-master: ~$ 





Pod 分 配 了 各 自 的 IP， 这 些 IP 只 能 被 Kubernetes Cluster JST 
点 访问 ， 如 图 6-3 所 示 。 


ubuntuek8s-master :~$ 
ubuntu@k8s-master:~$ curl 10.244.4.5 
«html»«body»«h1»It works!«/h1»«/body»«/html» 


ubuntuek8s-master : ~$ 

ubuntuék8s-master:-$ curl 10.244.5.4 
<htmL><body><h1>It works!«/h1»«/body»«/html- 
ubuntuéek8s-master : ~$ 


图 6-3 
接 下 来 创建 Service， 其 配置 文件 如 图 6-4 所 示 。 





apiVersion: v1 (1) 
kind: Service (9 
metadata: x 
name: httpd-svc (3 
spec: 
selector: 


run: httpd (4 
ports: 
- protocol: TCP 5 
port: 
targetPort: 





(D v1 ServiceHJapiVersion. 

(2) 指明 当前 资源 的 类 型 为 Service。 

(3) Service 的 名 字 为 httpd-svc。 

(2 selector 指 明 挑 选 那些 label] 为 run: httpd 的 Pod 作 为 Service 的 后 端 。 
@ 将 Service 的 8080 端 口 映射 到 Pod 的 80 端 口 ， 使 用 TCP 协 议 。 


执行 kubectl apply 创 建 Service httpd-svc， 如 图 6-5 所 示 。 


ubuntuek8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl apply -f httpd-svc.yml 
service "httpd-svc" created 

ubuntuek8s master : ~$ 

ubuntu@k8s-master:~$ kubectl get service 


NAME CLUSTER-IP EXTERNAL-IP PORT(CS) AGE 
httpd-svc 10.99.229.179 . «none» 8080/TCP 7s 
kubernetes 10.96.0.1 <none> 443/TCP 2d 
ubuntu@k8s-master : ~$ 

图 6-5 





httpd-svc 分 配 到 一 个 CLUSTER-IP ”10.99.229.179。 可 以 通过 该 IP 访 
问 后 端的 httpd Pod， 如 图 6-6 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ curl 10.99.229.179:8080 
<html><body><hi>It works!«/h1»«/body»«/html» 
ubuntu@k8s-master: ~$ 





图 6-6 


根据 前 面 的 端口 映射 ， 这 里 要 使 用 8080 端 口 。 另 外 ， 除 了 我 们 创建 
的 httpd-svc， 还 有 一 个 Service kubernetes，Cluster 内 部 通过 这 个 Service 访 
问 Kubernetes API Server. 


通过 kubectl describen] 以 查看 httpd-svc 与 Pod 的 对 应 关系 ， 如 图 6-7 所 


ZN o 


ubuntu@k&s-master : ~$ 
ubuntu@k&s-master:~$ kubectl describe service httpd-svc 
Name: httpd-svc 
Namespace: default 
Labels: <none> 
Annotations: kubectl.kubernetes.io/last-applied-configuration 
:8080,"protocol":" v 
Selector: run-httpd 
ClusterIP 
10.99.229.179 
<unset> E Gt 


Session AT 
Events: <none> 
ubuntu@k8s-master : 





图 6-7 


Endpoints 罗 列 了 三 个 Pod 的 IP 和 端口 。 我 们 知道 Pod 的 IP 是 在 容器 中 
配置 的 ， 那 么 Service 的 Cluster 耳 又 是 配置 在 哪里 的 呢 ? CLUSTER-IP 又 
是 如 何 映射 到 Pod IP 的 呢 ? 


答案 是 iptables。 


6.2 Cluster IP 底层 实现 


Cluster 了 是 一 个 虚拟 卫 ， 是 由 Kubernetes 节 点 上 的 iptables 规 则 管理 
HJ. 


可 以 通过 iptables-save 命 令 打 印 出 当前 节点 的 iptables 规 则 ， 因 为 输 
出 较 多 ， 这 里 只 截取 与 httpd-svc Cluster IP 10.99.229.179 相 关 的 信息 ， 如 
图 6-8 所 示 。 


-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.99.229.179/32 -p tcp -m comment -comment “default/httpd-svc: 
Cluster IP" -m tcp -dport 8080 -j KUBE-MARK-MASQ 
-A KUBE-SERVICES -d 10.99.229.179/32 -p tcp -m comment -comment “default/httpd-svc: Cluster IP" -m tcp 


-dport 8080 -j KUBE-SVC-RL3JAE4GN7VOGDGP 





这 两 条 规则 的 含义 是 : 


(1) 如果 Cluster 内 的 Pod《〈 源 地 址 来 自 10.244.0.0/16) 要 访问 httpd- 
svc， 则 人 允许 。 


(2) 其 他 源 地 址 访问 httpd-svc， 跳 转 到 规则 KUBE-SVC- 
RL3JAE4GN7VOG DGP。KUBE-SVC-RL3JAE4GN7VOGDGP 规 则 如 图 
6-9 所 示 。 


-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment "default/httpd- 
svc: " -m statistic -mode random -probability 0.33332999982 - 
j KUBE-SEP-C5KB52P4BBJQ35PH 


-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment *default/httpd-svc: " -m statistic -mode random -prob 
ability 0.33332999982 -j KUBE-SEP- Mess ei 
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment a ERa svc: ” -m statistic -mode random -prob 


ability 0.500009000000 -j KUBE-SEP-HGVKQQZZCF7RV4I 
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment es svc: " -j KUBE-SEP-XE25WGVXLHEIRVOS 


图 6-9 





(1) 1/3 的 概率 跳 转 到 规则 KUBE-SEP-C5KB52P4BBJQ35PH。 


(2) 1/3 的 概率 〈 剩 下 2/3 的 一 半 ) 跳 转 到 规则 KUBE-SEP- 
HGVKQQZZCF7RVAIT. 


(3) 1/3 的 概率 跳 转 到 规则 KUBE-SEP-XE25WGVXLHEIRVO5。 
上 面 三 个 跳 转 的 规则 如 图 6-10 所 示 。 


-A KUBE-SEP-C5KB52P4BBJQ35PH - vro 244.4.4/32 -| defai Ru. " -j KUBE-MARK- ML 

-A KUBE-SEP-C5KB52P4BBJQ35PH -p tcp -m comi ment © --comi paces "defa ini svc:" -m E DN, o-destin n 10.244.4.4:80 
-A KUBE-SEP-HGVKQQZZCF7RV41T -s ui m s Sic omment - ent "defa eetpas S ci" -j id 

-A KUBE-SEP-HGVKQQZZCF7RV4IT - ment --comment no lt/httpd- sve:" -m tc DN, -to-destination 10.244.4.5:80 


P: a 
-A KUBE-SEP-XE25WGVXLHEIRVOS -s T 244. wa - omment --comment "defa s petpa- svc:" -j KUBE-MARK-MASQ 
-A KUBE-SEP-XE25WGVXLHEIRVOS -p tcp -m men re --comment "default/httpd-svc:" -m tcp = DNAT --to-destination 10.244.5.4:80 





图 6-10 


即将 请 求 分 别 转发 到 后 端的 三 个 Pod。 通 过 上 面 的 分 析 ， 我 们 得 到 
结论 : iptables 将 访问 Service 的 流量 转发 到 后 端 Pod， 而 且 使 用 类 似 轮 询 
的 负载 均衡 策略 。 


另外 ， 需 要 补充 一 点 : Cluster 的 每 一 个 节点 都 配置 了 相同 的 iptables 
规则 ， 这 样 就 确保 了 整个 Cluster 都 能 够 通过 Service 的 Cluster IP 访 问 
Service， 如 图 6-11 所 示 。 


10.99.229.179 
Cluster IP 
(iptables) 
10.99,229.179 10.99.229.179 
Cluster IP Cluster IP 
(iptables) (iptables) 
oe httpd-741508562-6hh9g 
VERI (9 1024454 


AOD httpd-741508562-6g4fc 
[9) 1024444 


图 6-11 


63 DNS 访问 Service 


在 Cluster 中 ， 除 了 可 以 通过 Cluster IP 访 问 Service，Kubernetes 还 提 
供 了 更 为 方便 的 DNS 访问 。 


kubeadm 部 署 时 会 默认 安装 kube-dns 组 件 ， 如 图 6-12 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ kubectl get deployment --namespace=kube-system 
DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 

1 


al T 1 
ubuntu@k8s-master: ~$ 





5d 


图 6-12 


kube-dns 是 一 个 DNS 服务 器 。 每 当 有 新 的 Service 被 创建 ，kube-dns 
会 添加 该 Service 的 DNS 记录 。Cluster 中 的 Pod 可 以 通过 
«SERVICE NAME>.<NAMESPACE NAME >i [a] Service. 


比如 可 以 用 httpd-svc.default 访 问 Service httpd-svc， 如 图 6-13 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl run busybox --rm -ti --image=busybox /bin/sh 
If you don't see a command prompt, try pressing enter. 

/# 


/ # wgetlhttpd-svc.default:8080 
Connecting to httpd-svc.default:8080 (10.99.229.179:8080) 
index.html 45 0:00:00 ETA 


/ # 
图 6-13 


如 上 所 示 ， 我 们 在 一 个 临时 的 busybox Pod 中 验证 了 DNS 的 有 效 性 。 
另外 ， 由 于 这 个 Pod 与 httpd-svc 同 属于 default namespace， 因 此 可 以 省 略 
default 直 接 用 httpd-svc 访 问 Service， 如 图 6-14 所 示 。 


/ € wget|httpd-svc:8080 


Connecting to httpd-svc:8080 (10.99.229.179:8080) 





index.html 





/ # 


图 6-14 


用 nslookup 碍 看 httpd-svc 的 DNS 信息 ， 如 网 6-15 所 示 。 


/ # 
/ € nslookup httpd-svc 
10.96.0.10 
: 10.96.0.10 kube-dns.kube-system.svc.cluster.local 


httpd-svc 
: 10.99.229.179 httpd-svc.default.svc.cluster.local 





图 6-15 





DNS 服务 器 是 kube-dns.kube-system.svc.cluster.local， 这 实际 上 就 是 
kube-dns 组 件 ， 它 本 映 是 部 署 在 kube-system namespace 中 的 一 个 
Service. 





httpd-svc.default.svc.cluster.local 是 httpd-svc 的 完整 域名 。 


如 果 要 访问 其 他 namespace 中 的 Service， 就 必须 带 上 namesapce 了 。 
kubectl get namespace 碍 看 已 有 的 namespace， 如 网 6-16 所 示 。 


ubuntuek8s-master :~$ 
ubuntu@k8s-master:~$ kubectl get namespace 
NAME STATUS 
default Active 


kube-public Active 
kube-system Active 
ubuntu@k8s-master : ~$ 





在 kube-public 中 部 署 Service httpd2-svc， 配 置 如 图 6-17 所 示 。 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 

name: httpd2 

namespace: kube-public 
spec: 

replicas: 

template: 

metadata: 

labels: 
run: httpd2 

spec: 

containers: 

- name: httpd2 
image: httpd 
ports: 

- containerPort: 


apiVersion: v1 
kind: Service 
metadata: 
name: httpd2-svc 
namespace: kube-public 
spec: 
selector: 
run: httpd2 
ports: 
- protocol: TCP 
port: 
targetPort: 


图 6-17 





通过 namespace: kube-public 指 定 资源 所 属 的 namespace。 多 个 资源 可 
以 在 一 个 YAML 文 件 中 定义 ， 用 “---” 分 割 。 执 行 kubectl apply 创 建 资 
源 ， 如 图 6-18 所 示 。 


ubuntuek8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl apply -f httpd2.yml 
deployment "httpd2" created 


service "httpd2-svc" created 
ubuntu@k8s-master: ~$ 





图 6-18 


查看 kube-public 的 Service， 如 图 6-19 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get service --namespace-kube-public 
NAME CLUSTER-IP EXTERNAL-IP PORTCS) AGE 


httpd2-svc 10.103.198.189 <none> 8080/TCP 2m 
ubuntu@k8s-master : ~$ 





图 6-19 


在 busybox Pod 中 访问 httpd2-svc， 如 图 6-20 所 示 。 


ubuntu@k8s-master: ~$ 

ubuntu@k8s-master:~$ kubectl run busybox --rm -ti --image-busybox /bin/sh 
If you don't see a command prompt, try pressing enter. 

/ # 

/ # wget wget httpd2-svc:8080 

wget: bad address 'wget' 


/ # 
/ € wget httpd2-svc.kube-public: 8080 
Connecting to httpd2-svc.kube-public: 8080 (10.103.198.189: 8080) 


index.html 1009 |3kdok a A AR AR kk | 45 0:00:00 ETA 


/ # 





图 6-20 


因为 不 属于 同一 个 namespace， 所 以 必须 使 用 httpd2-svc.kube-public 
才能 访问 到 。 





6.4 外 网 如 何 访问 Service 


除了 Cluster 内 部 可 以 访问 Service， 很 多 情况 下 我 们 也 希望 应 用 的 
Service 能 够 暴露 给 Cluster 外 部 。Kubernetes 提 供 了 多 种 类 型 的 Service， 
默认 是 ClusterIP 。 


(1) ClusterIP 
Service 通 过 Cluster 内 部 的 IP 对 外 提供 服务 ， 只 有 Cluster 内 的 节点 和 
Pod 可 访问 ， 这 是 默认 的 Service 类 型 ， 前 面 实 验 中 的 Service 都 是 
ClusterIP 。 
(2) NodePort 


Service 通 过 Cluster 节 点 的 静态 端口 对 外 提供 服务 。Cjluster 外 部 可 以 
通过 <NodeIP>:<NodePort> 访 问 Service。 


(3) LoadBalancer 
Service 利 用 cloud provider 特 有 的 load balancer 对 外 提供 服务 ，cloud 
provider 负 责 将 load balancer 的 流量 导向 Service。 目 前 支持 的 cloud 
provider 有 GCP、AWS、Azur 等 。 


下 面 我 们 来 实践 NodePort，Service httpd-svc 的 配置 文件 修改 如 图 6- 
21 所 示 。 


apiVersion: v1 
kind: Service 
metadata: 

name: httpd-svc 


spec: 
type: NodePort 
selector: 


run: httpd 
ports: 
- protocol: TCP 
port: 
targetPort: 


图 6-21 





添加 type: NodePort， 重 新 创建 httpd-svc， 如 图 6-22 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl apply -f httpd-svc.yml 
service "httpd-svc" created 

ubuntu@k8s-master : ~$ 


ubuntu@k8s-master:~$ kubectl get service httpd-svc 

NAME CLUSTER-IP EXTERNAL-IP PORTCS AGE 
httpd-svc 10.109.144.35 |<nodes> 8080:32312/TCP] 5s 
ubuntuék8s master: ~$ 





图 6-22 
Kubernetes 依 然 会 为 httpd-svc 分 配 一 个 ClusterIP， 不 同 的 是 : 


(1) EXTERNAL-IP 为 nodes， 表 示 可 通过 Cluster 每 个 节点 自身 的 了 
访问 Service。 


(2) PORT(S) 为 8080:32312。8080 是 ClusterIP 监 听 的 端口 ，32312 
则 是 节点 上 监听 的 端口 。Kubernetes 会 从 30000 一 32767 中 分 配 一 个 可 用 
Hom 口 ， 每 个 节点 都 会 监听 此 端口 并 将 请 求 转发 给 Service， 如 图 6-23 所 
Z^ o 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ netstat -anlgrep 32312 
32312 ee 


cp6 0 LISTEN 
ubuntu@k8s-master : ~$ 





图 6-23 


下 面 测试 NodePort 是 否 正常 工作 ， 如 图 6-24 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ curl 192.168.56.105:32312 
«html»«body»«hi»It works!«/h1»«/body»«/html» 
ubuntu@k8s-master: ~$ 

ubuntu@k8&s-master:~$ curl 192.168.56.106:32312 


<html><body><hi>It works! </h1></body></htm1l> 
ubuntu@k8s-master: ~$ 

ubuntu@k8s-master:~$ curl 192.168.56.107:32312 
«html»«body»«hi»It works! </h1></body></htm1> 
ubuntu@k8s-master: ~$ 





图 6-24 
通过 三 个 节点 IP+32312 端 口 都 能 够 访问 httpd-svc. 


接 下 来 我 们 深入 探讨 一 个 问题 : Kubernetes 是 如 何 将 <NodeIP>: 
<NodePort> 映 射 到 Pod 的 呢 ? 


与 ClusterIP 一 样 ， 也 是 借助 了 iptables。 与 ClusterIP 相 比 ， 每 个 节点 
的 iptables 中 都 增加 了 下 面 两 条 规则 ， 如 图 6-25 所 示 。 





-A KUBE-NODEPORTS -p tcp -m comment -comment *default/httpd-svc: " -m tcp --dport 32312 -j KUBE-MARK-M 


Q 
-A KUBE-NODEPORTS -p tcp -m comment -comment *default/httpd-svc: " -m tcp --dport 32312 -j KUBE-SVC-RL 
3JAE4GN7VOGDGP 





图 6-25 


规则 的 含义 是 : 访问 当前 节点 32312 端 口 的 请 求 会 应 用 规则 KUBE- 
SVC-RL3JAE4GN7VOGDGP， 内 容 如 图 6-26 所 示 。 


-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment *default/httpd-svc: " -m statistic -mode random -prob 
ability 0.33332999982 —j KUBE-SEP-C5KB52P4BBJQ35PH 

-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment *default/httpd-svc: " -m statistic -mode random -prob 
ability 0.50000000000 -j KUBE-SEP-HGVKQQZZCF7RV41T 

-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment *default/httpd-svc: " -j KUBE-SEP-XE25WGVXLHEIRVO5 





图 6-26 
其 作用 就 是 负载 均衡 到 每 一 个 Pod。 


NodePort 默 认 的 是 随机 选择 ， 不 过 我 们 可 以 用 nodePort 指 定 某 个 特 
定 端口 ， 如 图 6-27 所 示 。 


apiVersion: v1 
kind: Service 
metadata: 

: httpd-svc 


type: NodePort 
selector: 


run: httpd 
ports: 


- protocol: TCP 


port: 
targetPort: 





图 6-27 


现在 配置 文件 中 就 有 三 个 Port 了 : 








e nodePort 是 节点 上 监听 的 端口 。 
e port 是 ClusterIP 上 监听 的 端口 。 
。targetPort 是 Pod 监 听 的 端口 。 


最 终 ，Node 和 ClusterIP 在 各 自 端 口上 接收 到 的 请 求 都 会 通过 iptables 
转发 到 Pod 的 targetPort。 


应 用 新 的 nodePort 并 验证 ， 如 图 6-28 所 示 。 


ubuntuek8s-master : ~$ 

ubuntuék8s-master:-$ kubectl apply -f httpd-svc.yml 
service "httpd-svc" configured 

ubuntuek8s -master : ~$ 

ubuntuék8s-master:-$ kubectl get service httpd-svc 

NAME CLUSTER-IP EXTERNAL- IP PORTCS) 
httpd-svc 10.109.144.35 <nodes> 8080 : 30000/TCP 


ubuntu@k8s-master: ~$ 

ubuntu@k8s-master:~$ curl 192.168.56.105:30000 
«html»«body»«h1»It works! </h1></body></htm1> 
ubuntu@k8s-master:~$ curl 192.168.56.106:30000 
«html»«body»«h1»It works! </h1></body></htm1> 
ubuntu@k8s-master:~$ curl 192.168.56.107:30000 
«html»«body»«h1»It works! </h1></body></htm1> 
ubuntu@k8s-master : ~$ 





图 6-28 


nodePort: 30000 己 经 生效 了 。 


65 小结 


本 章 我 们 讨论 访问 应 用 的 机 制 Service， 学 习 了 如 何 创建 Service， 
Service 的 三 种 类 型 ClusterIP、NodePort 和 LoadBalancer， 以 及 它们 各 自 
的 适用 场景 。 


27% Rolling Update 


深 动 更 新 是 一 次 只 更 新 一 小 部 分 副本 ， 成 功 后 再 更 新 更 多 的 副本 ， 
最 终 完成 所 有 副本 的 更 新 。 滚 动 更 新 的 最 大 好 处 是 零 停 机 ， 整 个 更 新 过 
程 始终 有 副本 在 运行 ， 从 而 保证 了 业务 的 连续 性 。 











7.4 XR 


下 面 我 们 部 署 三 副本 应 用 ， 初 始 镜 像 为 httpd:2.2.31， 然 后 将 


到 httpd:2.2.32。 
httpd:2.2.31 的 配置 文件 如 图 7-1 所 示 。 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 
name: httpd 
spec: 
replicas: 
template: 
metadata: 
Labels: 
run: httpd 
spec: 
containers: 
httpd 


containerPort: 


图 7-1 


通过 kubectl apply 部 晋 ， 如 图 7-2 所 示 。 


ubuntu@k8s-master :~$ 

ubuntu@k8s-master:~$ kubectl apply -f httpd.yml 

deployment "httpd" created 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get deployment httpd -o wide 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINER(S) SELECTOR 
httpd 3 3 3 3 8s httpd httpd:2.2.31] run=httpd 
ubuntu@k8s-master :~$ 

ubuntu@k8s-master:~$ kubectl get replicaset -o wide 





NAME DESIRED CURRENT READY AGE CONTAINER(S) IMAGE(S) SELECTOR 
httpd-551879778 3 3 3 13s httpd ht : pod-template-hash-55 


ubuntuek8s-master:-$ 

ubuntuék8s-master:-$ kubectl get pod 

NAME READY STATUS RESTARTS AGE 
httpd-551879778- jkxn4 1/1 Running 19s 
httpd-551879778-n3sqv 1/1 Running 19s 
httpd-551879778-zdfkt 1/1 Running 19s 


ubuntu@k8s-master:~$ 


图 7-2 





其 更 新 


HB EEO T: 

(1) 创建 Deployment httpd. 

(2) 创建 ReplicaSet httpd-551879778. 
(3) 创建 三 个 Pod。 


(4) 当前 镜像 为 httpd:2.2.31。 





将 配置 文件 中 的 httpd:2.2.31 蔡 换 为 httpd:2.2.32， 再 次 执行 kubectl 


apply， 如 网 7-3 所 示 。 


ubuntu@k8s-master: ~§ 

ubuntu@k8s-master: > n apply -f httpd.yml 
deployment "httpd" configured 

ubuntuek8s master: ~$ 

ubuntuék8s-master:-$ kubectl get deployment httpd -o wide 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERCS) IMAGE(S) SELECTOR 
httpd 3 3 3 3 1m httpd httpd:2.2.32]| run-httpd 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ kubectl get replicaset -o wide 


NAME DESIRED CURRENT READY AGE CONTAINERCS) IMAGE(S) 
httpd-1276601241 3 3) 3 9s httpd httpd:2.2.32 
httpd-551879778 0 0 0 2m httpd httpd:2.2.31 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ kubectl get pod 


NAME READY STATUS RESTARTS 
httpd-1276601241-26jx3 1/1 Uu ing 0 
httpd-1276601241-27kh7 1/1 

httpd-1276601241-pwrt7 1/1 ES ing 
ubuntu@k8s-master: ~$ 


我 们 发 现 了 如 下 变化 : 
(1) Deployment httpd 的 镜像 更 新 为 httpd:2.2.32。 


(2) 新 创建 了 ReplicaSet ”httpd-1276601241， 镜 像 为 httpd:2.2.32， 


并 且 管 理 了 三 个 新 的 Pod。 


(3) 之 前 的 ReplicaSet httpd-551879778 里 面 已 经 没有 任何 Pod。 


结论 是 : ReplicaSet httpd-551879778 的 三 个 httpd:2.2.31 Pod 已 经 被 


SELECTOR 
pod-template-hash 
pod-template-hash 





ReplicaSet httpd-1276601241 的 三 个 httpd:2.2.32 Pod 蔡 换 了 。 


具体 过 程 可 以 通过 kubectl describe deployment httpd 查 看 ， 如 图 7-4 所 


From SubObjectPath 


deployment-controller rm ScalingReplicaSet tp 
deployment-controller Normal ScalingReplicaSet T et E -1276601241 to 1 
deployment-controller mi ScalingReplicaSet Sealed pem replica set httpd-551879778 to 2 


deployment-controller ni ScalingReplicaSet 
deployment-controller Nori ScalingReplicaSet 
deployment-controller LT ScalingReplicaSet 
deployment-controller rm ScalingReplicaSet Scaled down replica set httpd- eee "i d 





每 次 只 更 新 蔡 换 一 个 Pod: 
(1) ReplicaSet httpd-1276601241 增 加 一 个 Pod， 总 数 为 1。 
(2) ReplicaSet httpd-551879778 减 少 一 个 Pod， 总 数 为 2。 
(3) ReplicaSet httpd-1276601241 增 加 一 个 Pod， 总 数 为 2。 
(4) ReplicaSet httpd-551879778 减 少 一 个 Pod， 总 数 为 1。 
(5) ReplicaSet httpd-1276601241 增 加 一 个 Pod， 总 数 为 3。 
(6) ReplicaSet httpd-551879778 减 少 一 个 Pod， 总 数 为 0。 
每 次 蔡 换 的 Pod 数 量 是 可 以 定制 的 。Kubernetes 提 供 了 两 个 参数 


maxSurge 和 maxUnavailable 来 精细 控制 Pod 的 谷 换 数量 ， 我 们 将 在 后 面 结 
合 Health Check 特 性 一 起 讨论 。 


7.2 EIX 


kubectl apply 每 次 更 新 应 用 时 ，Kubermetes 都 会 记录 下 当前 的 配置 ， 
保存 为 一 个 revision 〈 版 次 ) ， 这 样 就 可 以 回 滚 到 某 个 特定 revision 。 


默认 配置 下，Kubernetes 只 会 保留 最 这 的 儿 个 revision， 可 以 在 
Deployment 配 置 文件 中 通过 revisionHistoryLimit 属 性 增加 revision 数 量 。 


下 面 实践 回 深 功能。 应 用 有 三 个 配置 文件 ， 即 httpd.v1.yml、 
httpd.v2.yml 和 httpd.v3.yml， 分 别 对 应 不 同 的 httpd 镜 像 2.4.16、2.4.17 和 
2.4.18， 如 图 7-5、 图 7-6、 图 7-7 所 示 。 





apiVersion: apps/vibetal 
kind: Deployment 
metadata: 
name: httpd 
spec: 
revisionHistoryLlimit: 
replicas: 
template: 
metadata: 
labels: 
run: httpd 
spec: 
containers: 


image: SEHE 2.4.16 
E ry 


图 7-5 





apiVersion: apps/vibetal 
kind: Deployment 
metadata: 
name: httpd 
spec: 
revisionHistoryLimit: 
replicas: 
template: 
metadata: 
Labels: 
run: httpd 
spec: 
containers: 
- name: httpd 
ports: 
- containerPort: 


图 7-6 





apiVersion: apps/vibetal 
kind: Deployment 
metadata: 
name: httpd 
spec: 
revisionHistoryLimit: 
replicas: 
template: 
metadata : 

labels: 
run: httpd 

spec: 

containers: 

- name: httpd 
image: httpd:2.4.18 
ports: 

- containerPort: 


图 7-7 
通过 kubectl apply 部 署 并 更 新 应 用 ， 如 图 7-8 所 示 。 





ubuntuek8s-master:-$ 
ubuntu@k8s-master:~$ kubectl apply -f httpd.v1.yml (£-record) 
deployment "httpd" created 
ubuntuek8s master : ~$ 
ubuntu@k8s-master:~$ kubectl get deployment httpd -o wide 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERCS) IMAGE(S) SELECTOR 
httpd — 3 3 3 3 8s httpd run=httpd 
ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl apply -f httpd. v2.yml (record) 
deployment "httpd" configured 
ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get deployment httpd -o wide 
DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINER(S) IMAGE(S) SELECTOR 
3 3 3 27s httpd run=httpd 
~$ 
ubuntu@k8s-master:~$ kubectl apply -f httpd.v3.yml 
deployment "httpd" configured 
ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get deployment httpd -o wide 
DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINER(S) IMAGECS) SELECTOR 


3 3 5 3 51s httpd run=httpd 
ubuntu@k8s-master : ~$ 


--record 的 作用 是 将 当前 命令 记录 到 revision 记 录 中 ， 这 样 我 们 就 可 
以 知道 每 个 revison 对 应 的 是 哪个 配置 文件 了 。 通 过 kubect] rollout history 
deployment httpd 查 看 revison 历 史记 录 ， 如 图 7-9 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl rollout history deployment httpd 

deployments "httpd" 

REVISION CHANGE -CAUSE 
kubectl apply --filename=httpd.v1.yml --record-true 
kubectl apply --filename-httpd.v2.yml --record-true 
kubectl apply --filename-httpd.v3.yml --record-true 








ubuntu@k8s-master : ~$ 


图 7-9 


CHANGE-CAUSE 就 是 --record 的 结果 。 如 果 要 回 深 到 某 个 版 本 ， 比 
如 revision 1， 可 以 执行 命令 kubectl rollout undo deployment httpd --to- 
revision=1， 如 图 7-10 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl rollout undo deployment httpd --to-revision=1 

deployment "httpd" rolled back 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get deployment httpd -o wide 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERCS) IMAGE(S SELECTOR 
httpd 3 3 3 3 8m httpd run=httpd 


ubuntu@k8s-master : ~$ 
图 7-10 


此 时 ，revison 历 史记 录 也 会 发 生 相 应 变化 ， 如 图 7-11 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl rollout history deployment httpd 
deployments "httpd" 

REVISION CHANGE-CAUSE 





kubectl apply --filename=httpd.v2.yml --record=true 
kubectl apply --filename=httpd.v3.yml --record=true 
kubectl apply --filename-httpd.v1.yml --record=true 





ubuntu@k8s-master : ~$ 


图 7-11 


revison 1 变 成 了 revison 4。 不 过 我 们 可 以 通过 CHANGE-CAUSE 知 道 
每 个 revison 的 具体 含义 ， 所 以 一 定 要 在 执行 kubectl apply 时 加 上 --record 


MZ 


B 


7.3 小结 


本 章 我 们 学 习 了 滚动 更 新 。 滚 动 更 新 采用 渐进 的 方式 逐步 蔡 换 旧 版 
本 Pod。 如 果 更 新 不 如 预期 ， 可 以 通过 回 深 操 作 恢 复 到 更 新 前 的 状态 。 


75845: Health Check 


强大 的 自 愈 能 力 是 Kubernetes 这 类 容器 编排 引擎 的 一 个 重要 特性 。 
目 盒 的 默认 实现 方式 是 自动 重启 发 生 故 障 的 容器 。 除 此 之 外 ， 用 户 还 可 
以 利用 Liveness 和 Readiness 探 测 机 制 设置 更 精细 的 健康 检查 ， 进 而 实现 
如 下 需求 : 
(1) FEHLER. 
(2) 避免 部 署 无 效 的 镜像 。 
(3) 更 加 安全 的 滚动 升级 。 


下 面 通过 实践 学 习 Kubernetes 的 Health Check 功 能 。 











8.1 默认 的 健康 检查 





我 们 首先 学 习 Kubernetes 默 认 的 健康 检查 机 制 : 每 个 容器 启动 时 都 
会 执行 一 个 进程 ， 此 进程 由 Dockerfile 的 CMD 或 ENTRYPOINT 指 定 。 如 
果 进 程 退 出 时 返回 码 非 零 ， 则 认为 容器 发 生 故 障 ，Kubernetes 就 会 根据 


restartPolicy 重 启 容器 。 


ZN o 


FARII 





apiVersion: v1 
kind: Pod 
metadata: 
labels: 
test: healthcheck 
name: healthcheck 


spec: 


restartPolicy: OnFailure 


containers: 
- name: healthcheck 
image: busybox 
args: 
- /bin/sh 
- -C 


- sleep 10; exit 
图 8-1 





Pod 的 restartPolicy 设 置 为 OnFailure， 默 认为 Always。 
sleep 10; exit 1 模拟 容器 启动 10 秒 后 发 生 故 障 。 
执行 kubectl apply 创 建 Pod， 命 名 为 healthcheck， 如 图 8-2 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl apply -f healthcheck.yml 


pod "healthcheck" created 





ubuntu@k8s-master : ~$ 


图 8-2 
过 几 分 钟 查 看 Pod 的 状态 ， 如 图 8-3 所 示 。 


个 容 露 发 生 故 障 的 场景 ，Pod 配 置 文件 如 图 8-1 所 


ubuntuek8s -master : ~$ 
ubuntu@k&8s-master:~$ kubectl get pod healthcheck 


NAME READY STATUS RESTARTS AGE 
healthcheck 1/1 Running 3 1m 
ubuntuek8s -master : ~$ 


图 8-3 
可 看 到 容器 当前 已 经 重启 了 3 次 。 


在 上 面 的 例子 中 ， 容 器 进程 返回 值 非 零 ，Kubernetes 则 认为 容器 友 
生 故 障 ， 需 要 重启 。 有 不 少 情况 是 发 生 了 故障 ， 但 进程 并 不 会 退出 。 比 
如 访问 Web 服 务 器 时 显示 500 内 部 错误 ， 可 能 是 系统 超载 ， 也 可 能 是 资 
源 死 锁 ， 此 时 httpd 进 程 并 没有 异常 退出 ， 在 这 种 情况 下 重启 容器 可 能 是 
最 直接 、 最 有 效 的 解决 方案 ， 那 我 们 如 何 利 用 Health” Check 机 制 来 处 理 
这 类 场景 呢 ? 


答案 就 是 Liveness 探 测 。 























8.2 Livenessi Jl 


Livenessi43ll| LEH P uf EA EI xe SC FT d e EERE. WR ER 
测 失 败 ，Kubernetes 就 会 重启 容器 。 


下 面 举例 说 明 ， 创 建 Pod， 如 图 8-4 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 

labels: 
test: liveness 

name: liveness 

spec: 

restartPolicy: OnFailure 

containers: 

- name: liveness 
image: busybox 
args: 

- /bin/sh 


- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 
livenessProbe: 
exec: 
command: 
= cat 


- /tmp/healthy 
initialDelaySeconds: 
periodSeconds: 





图 8-4 


启动 进程 首先 创建 文件 /tmp/healthy，30 秒 后 删除 ， 在 我 们 的 设 定 
中 ， 如 果 /tmp/healthy 文 件 存 在 ， 则 认为 容器 处 于 正常 状态 ， 反 之 则 发 生 


故障 。 


livenessProbe 部 分 定义 如 何 执行 Liveness 探 测 : 





(1) 探测 的 方法 是 : 通过 cat 命 令 检查 /tmp/healthy 文 件 是 否 存在 。 
MAME MATRA, 返回 值 为 零 ，Kubernetes 则 认为 本 次 Liveness 探 测 成 
Jj, 如 果 命 令 返 回 值 非 零 ， 林 次 Liveness 探 测 失败 。 


(2) initialDelaySeconds: 10 指 定 容器 启动 10 之 后 开始 执行 Liveness 
探测 ， 我 们 一 般 会 根据 应 用 局 动 的 准备 时 间 来 设置 。 比 如 某 个 应 用 正常 
启动 要 花 30 秒 ， 那 么 initialDelaySeconds 的 值 就 应 该 大 于 30。 


(3) periodSeconds: 5 指定 每 5 秒 执行 一 次 Liveness 探 测 。 
Kubernetes 如 果 连 续 执行 3 次 Liveness 探 测 均 失 败 ， 则 会 杀 掉 并 重启 容 
Ans 


下 面 创建 Pod liveness， 如 图 8-5 所 示 。 


ubuntuék8s -master : ~$ 
ubuntuék8s-master:-$ kubectl apply -f liveness.yml 


pod "liveness" created 
ubuntu@k8s-master: ~$ 





图 8-5 


从 配置 文件 可 知 ， 最 开始 的 30 秒 ，/tmp/healthy 存 在 ，cat 命 令 返 回 
0，Liveness 探 测 成 功 ， 这 上 段 时 间 kubectl describe pod liveness 的 Events 部 
分 会 显示 正常 的 日 志 ， 如 图 8-6 所 示 。 


Reason Message 


Scheduled Successfully assigned liveness to k8s-nodel 
SuccessfulMountVolume MountVolume.SetUp succeeded for volume "default-token-hnz?b" 
Pulling pulling image "busybox" 

Pulled Successfully pulled image "busybox" 

Created Created container 





35 秒 之 后 ， 日 志 会 显示 /tmp/healthy 已 经 不 存在 ，Liveness 探 测 失 
败 。 再 过 几 十 秒 ， 几 次 探测 都 失败 后 ， 容 器 会 被 重启 ， 如 图 8-7、 图 8-8 
所 示 。 


Reason Message 


Normal Scheduled Successfully assigned liveness to k8s-nodel 
Normal SuccessfulMountVolume MountVolume.SetUp succeeded for volume "default-token-hnz7b" 
6 {liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file 


Normal Pulling pulling image "busybox 

ormal Ki TU ETA EET docker://liveness:pod "liveness-detoultt308650ed-a32t-11e7-b249-080027445Tad 
_tainer "liveness" is unhealthy, it will be killed and re-created. — 

Normal Pulled Successfully pulled image "busybox" 

Normal Created Created container 

Normal Started Started container 


ubuntu@k8s-master: -$ kubectl get pod liveness 
NAME READY STATUS RESTARTS AGE 
liveness 1/1 Running 1 1m 





ubuntu@k8s-master : ~$ 


图 8-8 


8.3 Readiness? jii 


除了 Liveness 探 测 Kubernetes Health Check 机 制 还 包括 Readiness 探 
测 o 





用 户 通 过 Liveness 探 测 可 以 告诉 Kubernetes 什 么 时 候 通 过 重启 容器 实 
现 自 愈 ，Readiness 探 测 则 是 告诉 Kubernetes 什 么 时 候 可 以 将 容器 加 入 到 
Service 负 和 载 均衡 池 中 ， 对 外 提供 服务 。 


Readiness 探 测 的 配置 语法 与 Liveness 探 测 完 全 一 样 ， 如 图 8-9 中 的 例 
FATA .e 


apiVersion: v1 
kind: Pod 
metadata: 
labels: 
test: readiness 
name: readiness 


spec: 
restartPolicy: OnFailure 
containers: 
- name: readiness 
image: busybox 


args: 
- /bin/sh 
- =Ç 


- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 


exec: 

command: 

- cat 

- /tmp/healthy 
initialDelaySeconds: 
periodSeconds: 





图 8-9 


这 个 配置 文件 只 是 将 前 面 例子 中 的 liveness 蔡 换 为 了 readiness， 我 们 
看 看 有 什么 不 同 的 效果 ， 如 图 8-10 所 示 。 


ubuntu@k8s-master:~$ kubectl apply -f readiness. 
pod "readiness" created 

ubuntu@k8s-master : ~$ 

ubuntuek8s-master:-$ kubectl get pod readiness 


NAME READY STATUS RESTARTS | AGE 
readiness Running 0 9s 


ubuntu@k8s-master : ~$ 


ubuntuék8s-master:-$ kubectl get pod readiness 


NAME READY STATUS RESTARTS AGE 
readiness bra] Running 0 
ubuntuek8s master: ~$ 

ubuntuék8s-master:-$ kubectl get pod readiness 


NAME READY STATUS RESTARTS AGE 
readiness |0/1 Running 0 53s 


ubuntu@k8s-master: ~$ 





图 8-10 





Pod readiness 的 READY 状 态 经 历 了 如 下 变化 : 
(1) 刚 被 创建 时 ，READY 状 态 为 不 可 用 。 


(2) 15 秒 后 CinitialDelaySeconds + periodSeconds) ， 第 一 次 进行 
Readiness 探 测 并 成 功 返 回 ， 设 置 READY 为 可 用 。 


(3) 30 秒 后 ，Mmp/healthy 被 删除 ， 连 续 3 次 Readiness 探 测 均 失败 
后 ，READY 被 设置 为 不 可 用 。 


通过 kubectl describe pod readiness 也 可 以 看 到 Readiness 探 测 失 败 的 
如 图 8-11 所 示 。 


Reason Message 


Normal Scheduled Successfully assigned readiness to k8s-nodel 

Normal SuccessfulMountVolume MountVolume.SetUp succeeded for volume "default-token-hnz7b" 
Normal Pulling pulling image "busybo: 

Normal Pulled Successfully pulled image "busybox" 


Normal Created Created container 


Normal Started Started container 
[Warning Unhealthy Readiness probe failed: cat: can't open '/tmp/healthy':|No such file 


图 8-11 


下 面 对 Liveness 探 测 和 Readiness 探 测 做 个 比较 : 





(1) Liveness 探 测 和 Readiness 探 测 是 两 种 Health _ Check 机制， 如 果 
不 特意 配置 ， Kubernetes 将 对 两 种 探测 采取 相 同 的 默认 行为 ， 即 通过 判 
时 容 器 启动 进程 的 返回 值 是 否 为 零 来 判断 探测 是 否 成 功 。 


(20 两 种 探测 的 配置 方法 完全 一 样 ， 文 持 的 配置 参数 也 一 样 。 不 


同 之 处 在 于 探测 失败 后 的 行为 : Liveness 探 测 是 重启 容器 ; Readiness 探 
测 则 是 将 容器 设置 为 不 可 用 ， 不 接收 Service 转 发 的 请 求 。 


(3) Liveness 探 测 和 Readiness 探 测 是 独立 执行 的 ， 二 者 之 间 没 有 依 
赖 ， 所 以 可 以 单独 使 用 ， 也 可 以 同时 使 用 。 用 Liveness 探 测 判 断 容器 是 
否 需 要 重启 以 实现 自 愈 ， 用 Readiness 探 测 判 断 容器 是 否 已 经 准备 好 对 外 
提供 服务 。 


理解 了 Liveness 探 测 和 Readiness 探 测 的 原理 ， 接 下 来 讨论 如 何在 业 
务 场 景 中 使 用 Health Check。 





8.4 Health Check 在 Scale Up 中 的 应 
用 


对 于 多 副本 应 用 ， 当 执行 Scale Up 操作 时 ， 新 副本 会 作为 backend 被 
添加 到 Service 的 负载 均衡 中 ， 与 已 有 副本 一 起 处 理 客 户 的 请 求 。 考 虑 到 
应 用 启动 通常 都 需要 一 个 准备 阶段 ， 比 如 加 载 缓存 数据 、 连 接 数 据 库 
等 ， 从 容器 启动 到 真正 能 够 提供 服务 是 需要 一 段 时 间 的 。 我 们 可 以 通过 
Readiness 探 测 判断 容器 是 否 就 络 ， 避 免 将 请 求 发 送 到 还 没有 准备 好 的 
backend. 


示例 应 用 的 配置 文件 如 图 8-12 所 示 。 





apiVersion: apps/vibetai 
kind: Deployment 


replicas: 
template: 
metadata: 
labels: 
run: web 
spec: 
containers: 
- name: web 
image: myhttpd 
ports: 
- containerPort: 
| readinessProbe: 
httpGet: 
scheme: HTTP 
path: /healthy 
port: 
initialDelaySeconds: 
periodSeconds: 


apiVersion: v1 
kind: Service 
metadata: 
name: web-svc 
spec: 
selector: 
run: web 
ports: 
- protocol: TCP 
port: 
targetPort: 





图 8-12 
重点 关注 readinessProbe 部 分 。 这 里 我 们 使 用 了 不 同 于 exec 的 另 一 种 


探测 方法 httpGet。Kubernetes 对 于 该 方法 探测 成 功 的 判断 条 件 是 http 请 求 
的 返回 代码 在 200 一 400 之 间 。 


e schema 指 定 协议 ， 支 持 HTTP (默认 值 ) 和 HTTPS。 
。path 指 定 访 问 路 径 。 
e port 指 定 端口 。 

上 面 配置 的 作用 是 : 

(1) 容器 启动 10 秒 之 后 开始 探测 。 


(2) 如 果 http:W[container_ ip]:8080healthy 返 回 代 码 不 是 200 一 400， 
表示 容器 没有 就 绪 ， 不 接收 Service web-svc 的 请 求 。 


(3) 每 隔 5 秒 探测 一 次 。 


(4) 直到 返回 代码 为 200 一 400， 表 明 容 器 已 经 就 纤 ， 然 后 将 其 加 
入 到 web-svc 的 负载 均衡 中 ， 开 始 处 理 客 户 请 求 。 


(5) 探测 会 继续 以 5 秒 的 间隔 执行 ， 如 条 连续 发 生 3 次 失败 ， 容 需 
又 会 从 负载 均衡 中 移 除 ， 直 到 下 次 探测 成 功 重 新 加 入 。 


对 于 http://[container_ip]:8080/healthy， 应 用 则 可 以 实现 自己 的 判断 
逻辑 ， 比 如 检查 所 依赖 的 数据 库 是 否 束 绕 ， 示 例 代 码 如 图 8-13 所 示 。 


http.HandleFunc( , func(w http.ResponseWriter, r *http.Request) { (1 
healthy = True; 


// Check Database 
db = connect(dbIP, dbPort, dbUser, dbPassword) (2 


if db != NULL 1 
try { 
db .QueryC 
} catch (e){ 
err = e.message 
H 
H 


if db == NULL || err !- NULL { 
healthy = False 
errMsg += 


} 


if healthy { 
w.WriteC[]byte( D) (9 
} else 1 
// Send 


http.Error(w, errMsg, http.StatusServiceUnavailable) 4) 


b») 


http.ListenAndServe( 





图 8-13 
CD 定义 /healthy 的 处 理 函 数 。 

D 连接 数据 库 并 执行 测试 SQL 。 
O 测试 成 功 ， 正 常 返 回 ， 代 码 200。 
由 测试 失败 ， 返 回 错 误 代 码 503。 
(5) 在 8080 端 口 监听 。 


对 于 生产 环境 中 重要 的 应 用 ， 都 建议 配置 Health Check， 保 证 处 理 
客户 请 求 的 容器 都 是 准备 就 绪 的 Service backend. 


8.5 Health Check 在 滚动 更 新 中 的 应 
Hi 


Health Check 另 一 个 重要 的 应 用 场景 是 Rolling Update。 试 想 一 下 ， 
现 有 一 个 正常 运行 的 多 副本 应 用 ， 接 下 来 对 应 用 进行 更 新 (比如 使 用 更 
高 版 本 的 image) ，Kubernetes 会 局 动 新 副本 ， 然 后 发 生 了 如 下 事件 : 


C1) 正 第 情况 下 新 副本 需要 10 秒 钟 完成 准备 工作 ， 在 此 之 前 无 法 
啊 应 业务 请 求 。 


(2) 由 于 人 为 配置 错误 ， 副 本 始终 无 法 完成 准备 工作 《比如 无 法 
连接 后 端 数据 库 ) 。 


先 别 继续 往 下 看 ， 现 在 请 花 一 分 钟 思考 这 个 问题 : 如 果 没 有 配置 
Health Check， 会 出 现 怎 样 的 情况 ? 


因为 新 副本 本 喘 没 有 寞 第 退出 ， 上 默认 的 Health” ”Check 机制 会 认为 容 
名 已 经 环绕 ， 进 而 会 逐步 用 新 副本 亚 换 现 有 副本 ， 其 结果 束 是 : 当 所 有 
昌 副 本 都 被 蔡 换 后 ， 整 个 应 用 将 无 法 处 理 请 求 ， 无 法 对 外 提供 服务 。 如 
条 这 是 发 生 在 重要 的 生产 系统 上 ， 后 果 会 非常 严重 。 


如 果 正 确 配置 了 Health Check， 新 副本 只 有 通过 了 Readiness 探 测 才 
会 被 添加 到 Service; 如 果 没 有 通过 探测 ， 现 有 副本 不 会 被 全 部 蔡 换 ， 业 
务 仍然 正常 进行 。 

下 面 通过 例子 来 实践 Health Check 在 Rolling Update 中 的 应 用 。 


使 用 如 下 配置 文件 app.v1l.yml 模 拟 一 个 10 副 本 的 应 用 ， 如 图 8-14 所 
Re 

















apiVersion: apps/vibetal 
kind: Deployment 
metadata: 
name: app 
spec: 
replicas: 
template: 
metadata: 
labels: 


run: app 
spec: 
containers: 


- name: app 
image: busybox 
args: 
- /bin/sh 
- =C 
- sleep 10; touch /tmp/healthy; sleep 
readinessProbe: 
exec: 
command : 
- cat 
- /tmp/healthy 
initialDelaySeconds: 
periodSeconds: 


图 8-14 





10 秒 后 副本 能 够 通过 Readiness 探 测 ， 如 图 8-15 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl apply -f app.vi.yml --record 
deployment "app" created 

ubuntuék8s master : ~$ 

ubuntu@k8s-master:~$ kubectl get deployment app 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
app 10 10 10 10 28s 
ubuntuék8s master: ~$ 

ubuntu@k8s-master:~$ kubectl get pod 

NAME READY STATUS RESTARTS AGE 
app-2780995820-Ompfl 1/1 Running 32s 
app-2780995820-9nmfm 1/1 Running 32s 
app-2780995820-dqdwn 1/1 Running 32s 
app-2780995820-g0srs 1/1 Running 32s 
app-2780995820-g52wp 1/1 Running 32s 
app-2780995820-kddms 1/1 Running 32s 
app-2780995820-rrwsh 1/1 Running 32s 
app-2780995820-t3k14 1/1 Running 32s 
app-2780995820-v1qzn 1/1 Running 32s 
app-2780995820-z8qx4 1/1 Running 32s 
ubuntu@k8s-master:~$ 
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图 8-15 


接 下 来 滚动 更 新 应 用 ， 配 置 文件 app.v2.yml， 如 图 8-16 所 示 。 











apiVersion: apps/vibetai 
kind: Deployment 
metadata: 
name: app 
spec: 
replicas: 
template: 
metadata: 
labels: 


run: app 
spec: 
containers: 


- name: app 
image: busybox 
args: 
- /bin/sh 
- -C 
readinessProbe: 
exec: 
command : 
- cat 
- /tmp/healthy 
initialDelLaySeconds: 
periodSeconds: 


图 8-16 


很 显然 ， 由 于 新 副本 中 不 存在 /tmp/healthy， 因 此 是 无 法 通过 
Readiness 探 测 的 ， 验 证 如 图 8-17 所 示 。 








ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f app.v2.yml --record 
deployment "app" configured 

ubuntuéek8s master: ~$ 

ubuntu@k8s-master:~$ kubectl get deployment app 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
app 10 13 5 8 5m 
ubuntu@k8s-master :~ 

ubuntu@k8s-master:~$ kubectl get pod 

NAME READY STATUS RESTARTS AGE 
app-2780995820-Ompfl 1/1 Running 5m 
app-2780995820-g@srs 1/1 Running 5m 
app-2780995820-g52wp 1/1 Running 5m 
app-2780995820-kddms 1/1 Running 5m 
app-2780995820-rrwsh 1/1 Running 5m 
app-2780995820-t3k14 1/1 Running 5m 
app-2780995820-viqzn 1/1 Running 5m 
app-2780995820-z8qx4 1/1 Running 5m 
app-3350497563-d31s3 0/1 Running 
app-3350497563-fkjvq 0/1 Running 
app-3350497563-1tjp3 0/1 Running 
app-3350497563-qm92c 0/1 Running 
app-3350497563-vh56z 0/1 Running 
ubuntu@k8s-master: ~$ 


49s 
49s 
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图 8-17 


这 个 截图 包含 了 大 量 的 信息 ， 值 得 我 们 详细 分 析 。 


先 关 注 kubectl get pod 输 出 : 


(1) 从 Pod 的 AGE 栏 可 判断 ， 最 后 5 个 Pod 是 新 副本 ， 目 前 处 于 
NOT READY 状 态 。 


(2) 旧 副 本 从 最 初 10 个 减少 到 8 个 。 
再 来 看 kubectl get deployment app 的 输出 : 
(1) DESIRED 10 表 示 期 望 的 状态 是 10 个 READY 的 副本 。 


(2) CURRENT ”13 表示 当前 副本 的 总 数 ， 即 8 个 旧 副 本 +5 个 新 副 
A. 


(3) UP-TO-DATE 5 表示 当前 已 经 完成 更 新 的 副本 数 ， 即 5 个 新 副 
X. 


(4) AVAILABLE 8 表示 当前 处 于 READY 状 态 的 副本 数 ， 即 8 个 旧 
副本 。 


在 我 们 的 设 定 中 ， 新 副本 始终 都 无 法 通过 Readiness 探 测 ， 所 以 这 个 
状态 会 一 直 保 持 下 去 。 

上 面 我 们 模拟 了 一 个 深 动 更 新 失败 的 场景 。 不 过 幸运 的 是 : Health 
Check 帮 我 们 屏 贡 了 有 缺陷 的 副本 ， 同 时 保留 了 大 部 分 旧 副 本 ， 业 务 没 
有 因 更 新 失败 受到 影响 。 

接 下 来 我 们 要 回答 : 为 什么 新 创建 的 副本 数 是 5 个 ， 同 时 只 销毁 了 2 
个 旧 副 本 ? 


原因 是 : 滚动 更 新 通过 参数 maxSurge 和 maxUnavailable 来 控制 副本 
蔡 换 的 数量 。 


1. maxSurge 


此 参数 控制 滚动 更 新 过 程 中 副本 总 数 超过 DESIRED 的 上 限 。 
maxSurge 可 以 是 具体 的 整数 《比如 3) ， 也 可 以 是 百 分 百 ， 同 上 取 整 。 
maxSurge 默 认 值 为 25%。 








在 上 面 的 例子 中 ，DESIRED 为 10， 那 么 副本 总 数 的 最 大 值 为 
roundUp(10 + 10 * 25%) =13， 所 以 我 们 看 到 CURRENT 就 是 13。 


2. maxUnavailable 


此 参数 控制 滚动 更 新 过 程 中 ， 不 可 用 的 副本 相 占 DESIRED 的 最 大 
比例 。maxUnavailable 可 以 是 具体 的 整数 《〈 比 如 3) ， 也 可 以 是 百 分 百 ， 
向 下 取 整 。maxUnavailable 默 认 值 为 25%。 


在 上 面 的 例子 中 ，DESIRED 为 10， 那 么 可 用 的 副本 数 至 少 要 为 10 - 
roundDown(10 * 25%)= 8， 所 以 我 们 看 到 AVAILABLE 是 8。 


maxSurge 值 越 大 ， 初 始 创建 的 新 副本 数量 就 越 多 ;maxUnavailable 
值 越 大 ， 初 始 销毁 的 旧 副 本 数量 就 越 多 。 


理想 情况 下 ， 我 们 这 个 案例 滚动 更 新 的 过 程 应 该 是 这 样 的 : 

(1) 创建 3 个 新 副本 使 副本 总 数 达到 13 个 。 

(2) 销毁 2 个 旧 副 本 使 可 用 的 副本 数 降 到 8 个 。 

(3) 当 2 个 旧 副 本 成 功 销毁 后 ， 再 创建 2 个 新 副本 ， 使 副本 总 数 保 
持 为 13 个 。 (4 当 新 副本 通过 Readiness 探 测 后 ， 会 使 可 用 副本 数 增 
加 ， 超 过 8。 

(5) 进而 可 以 继续 销毁 更 多 的 旧 副 本 ， 使 可 用 副本 数 回 到 8。 
(6) 昌 副 本 的 销毁 使 副本 总 数 低 于 13， 这 样 束 允许 创建 更 多 的 新 
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换 ， 滚 动 更 新 完成 。 


而 我 们 的 实际 情况 是 在 第 4 步 融 卡 住 了 ， 新 副本 无 法 通过 Readiness 
探测 。 这 个 过 程 可 以 在 kubectl describe deployment app 的 日 志 部 分 查看 ， 
如 图 8-18 所 示 。 





Message 


ScalingReplicaSet Scaled up replica set app-2780995820 to 10 


ScalingReplicaSet Scaled up replica set app-3350497563 to 3 
ScalingReplicaSet Scaled down replica set app-2780995820 to 8 
Normal ScalingReplicaSet Scaled up replica set app-3350497563 to 5 


图 8-18 


如 果 滚 动 更 新 失败 ， 可 以 通过 kubectl rollout undo 回 滚 到 上 一 个 版 
本 ， 如 图 8-19 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl rollout history deployment app 
deployments "app 
REVISION CHANGE-CAUSE 

1 kubectl apply --filename=app.v1.yml --record=true 
2 kubectl apply --filename=app.v2.yml --record=true 





ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl rollout undo deployment app --to-revision=1 
deployment "app" rolled back 

ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get deployment app 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 

app 10 10 10 10 1h 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod 

NAME READY STATUS RESTARTS 

app-2780995820-Ompf1 1/1 Running 
app-2780995820-bq3zd 1/1 Running 
app-2780995820-g@srs 1/1 Running 
app-2780995820-g52wp 1/1 Running 
app-2780995820-kddms 1/1 Running 
app-2780995820-mOcvr 1/1 Running 
app-2780995820-rrwsh 1/1 Running 
app-2780995820-t3kl4 1/1 Running 
app-2780995820-viqzn 1/1 Running 
app-2780995820-z8qx4 1/1 Running 
ubuntu@k8s-master :~ 


esooooooo 3 





图 8-19 


如 果 要 定制 maxSurge 和 maxUnavailable， 可 以 进行 如 图 8-20 所 示 的 
配置 : 


apiVersion: apps/vibetai 
kind: Deployment 
metadata: 
name: app 
spec: 
strategy: 
rollingUpdate: 
maxSurge: 35% 
| maxUnavailable: 35% 
replicas: 
template: 
metadata: 
labels: 
run: app 
spec: 


containers: 


- name: app 
image: busybox 
args: 
- /bin/sh 
- -C 
- sleep 
readinessProbe: 
exec: 
command : 
- cat 
- /tmp/healthy 
initialDelaySeconds : 
periodSeconds: 





图 8-20 


8.6 小结 


本 章 我 们 讨论 了 Kubernetes 健 康 检查 的 两 种 机 制 : Liveness 探 测 和 
Readiness 探 测 ， 并 实践 了 健康 检查 在 Scale Up 和 Rolling Update 场 景 中 的 
应 用 。 


本 章 将 讨论 Kubernetes 如 何 管理 存储 资源 。 


首先 我 们 会 学 习 Volume， 以 及 Kubernetes 如 何 通 过 Volume 为 集群 中 
的 容器 提供 存储 ; 然后 我 们 会 实践 几 种 常用 的 Volume 类 型 并 理解 它们 
各 自 的 应 用 场景 ， 最 后 ， 我 们 会 讨论 Kubernetes 如 何 通 过 Persistent 


Volume 和 Persistent Volume Claim 分 离 集群 管理 员 与 集群 用 户 的 职责 ， 
并 实践 Volume 的 静态 供给 和 动态 供给 。 


9.1 Volume 


本 节 我 们 讨论 Kubernetes 的 存储 模型 Volume， 学 习 如 何 将 各 种 持久 
METERS SUITS o 


我 们 经 常会 说 : 容器 和 Pod 是 短暂 的 。 其 含义 是 它们 的 生命 周期 可 
能 很 得， 会 被 频繁 地 销毁 和 创建 。 容 器 销毁 时 ， 保 存在 容器 内 部 文件 系 
统 中 的 数据 都 会 被 清除 。 

为 了 持久 化 保存 容器 的 数据 ， 可 以 使 用 Kubernetes Volume. 


Volume 的 生命 周期 独立 于 容器 ，Pod 中 的 容器 可 能 被 销毁 和 重建 ， 
但 Volume 会 被 保留 。 





本 质 上 ，Kubernetes Volume 是 一 个 目录 ， 这 一 点 与 Docker Volume 
类 似 。 当 Volume 被 mount 到 Pod，Pod 中 的 所 有 容器 都 可 以 访问 这 个 
Volume. Kubernetes Volume 也 文 持 多 种 backend 类 型 ， 包 括 emptyDir、 
hostPath、GCE Persistent Disk. AWS Elastic Block Store、 NFS、Ceph 
等 ， 完 整 列 表 可 参考 
https://kubernetes.io/docs/concepts/storage/volumes/Ztypes-of-volumes. 


Volume 提 供 了 对 各 种 backend 的 抽象 ， 容 器 在 使 用 Volume 读 写 数据 
的 时 候 不 需要 关心 数据 到 底 是 存放 在 本 地 节点 的 文件 系统 中 还 是 云 硬 檀 
上 。 对 它 来 说 ， 所 有 类 型 的 Volume 都 只 是 一 个 目录 。 


我 们 将 从 最 简单 的 emptyDir 开 始 学 习 Kubernetes Volume. 


9.1.1 emptyDir 


emptyDir 是 最 基础 的 Volume 类 型 。 正 如 其 名 字 所 示 ， 一 个 emptyDir 
Volume 是 Host 上 的 一 个 空 目录 。 








emptyDir Volume 对 于 容 吉 来 说 是 持久 的 ， 对 于 Pod 则 不 是 。 当 Pod 
从 节点 删除 时 ，Volume 的 内 容 也 会 被 删除 。 但 如 有 果 只 是 容器 被 销毁 而 
Pod 还 在 ， 则 Volume 不 受 影响 。 





也 就 是 说 : emptyDir Volume 的 生命 周期 与 Pod 一 致 。 


Pod 中 的 所 有 容器 都 可 以 共享 Volume， 它 们 可 以 指定 各 自 的 mount 
路 径 。 下 面 通过 例子 来 实践 emptyDir， 配 置 文件 如 图 9-1 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 
name: producer-consumer 
spec: 
containers: 
- image: busybox 
name: producer 
volumeMounts: 
- mountPath: /producer_dir 
name: shared-volume 
args: 
- /bin/sh 


> /producer dir/hello ; sleep 


- image: busybox 
name: consumer 
volumeMounts : 
- mountPath: /consumer. dir 
name: shared-volume 
args: 
- /bin/sh 
- -C 
- cat /consumer_dir/hello ; sleep 


volumes: 
- name: shared-volume 
emptyDir: {} 





图 9-1 


这 里 我 们 模拟 了 一 个 producer-consumer 场 景 。Pod 有 两 个 容器 
producer 和 consumer， 它 们 共享 一 个 Volume。producer 人 负责 往 Volume 中 
写 数据 ，consumer 则 是 从 Volume 读 取 数 据 。 


O 文件 最 底部 volumes 定 义 了 一 个 emptyDir 类 型 的 Volume shared- 
volume. 


(2) producer 28 Tf shared-volume mount Zl/producer. dirH 3 
(3) producer 通 过 echo 将 数据 写 到 文件 hello 里 。 

(4) consumer 容 器 将 shared-volume mount#!|/consumer_dir H 3&. 
©) consumer 通 过 cat 从 文件 hello 读 数据 。 

执行 命令 创建 Pod， 如 图 9-2 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl apply -f emptyDir.yml 


pod "producer-consumer" created 
ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get pod 


NAME READY STATUS RESTARTS AGE 
producer-consumer 2/2 Running 0 15s 
ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl logs producer-consumer consumer 


hello world 
图 9-2 


kubectl logs 显 示 容器 consumer 成 功 读 到 了 producer 写 入 的 数据 ， 验 
证 了 两 个 容器 共享 emptyDir Volume. 


因为 emptyDir 是 Docker Host 文 件 系 统 里 的 目录 ， 其 效果 相当 于 执行 
了 docker run -v/producer_dir 和 docker run -v /consumer_dir。 通 过 docker 
inspect 查 看 容器 的 详细 配置 信息 ， 我 们 发 现 两 个 容器 都 mount 了 同一 个 
目录 ， 如 图 9-3、 图 9-4 所 示 。 





"mounts": [ 
i 
"Source": "/var/1lib/kubelet/pods/3e6100eb-a97a-11e7-8f72-080027 
4451ad/volumes/kubernetes.io-empty-dir/shared-volume", 
"Destination": "/producer dir", 
"Mode": "", 
"RW": true, 
"Propagation": "rprivate" 





图 9-3 


"mounts": [ 


"Source": "/var/lib/kubelet/pods/3e6100eb-a97a-11e7-8f72-080027 
4451ad/volumes/kubernetes.io-empty-dir/shared-volume", 


"Destination": "/consumer. dir", 
"Mode": "" 

"RW": true, 

"Propagation": "rprivate" 


}, 





图 9-4 


ix FA /var/lib/kubelet/pods/3e6100eb-a97a-11e7-8f72- 
0800274451ad/volumes/kubernetes. io~ empty-dir/shared-volume Hit z€ 


emptyDir 在 Host 上 的 真正 路 径 。 


emptyDir 是 Host 上 创建 的 临时 目录 ， 其 优点 是 能 够 方便 地 为 Pod 中 
的 容器 提供 共享 存储 ， 不 需要 额外 的 配置 。 它 不 具备 持久 性 ， 如 果 Pod 
不 存在 了 ，emptyDir 也 就 没有 了 。 根 据 这 个 特性 ，emptyDir 特 别 适 合 
a 比如 前 面 的 生产 者 消费 者 
9 。 


9.1.2 hostPath 


hostPath Volume 的 作用 是 将 Docker Host 文 件 系 统 中 已 经 存在 的 目录 
mount 给 Pod 的 容器 。 大 部 分 应 用 都 不 会 使 用 hostPath Volume， 因 为 这 实 
际 上 增加 了 Pod 与 节点 的 耘 合 ， 限 制 了 Pod 的 使 用 。 不 过 那些 需要 访问 
ELI ANS 内 部 数据 (配置 文件 和 二 进 制 库 ) 的 应 用 则 需要 使 
hostPath. 


比如 kube-apiserver 和 kube-controller-manager 就 是 这 样 的 应 用 ， 通 过 
kubectl edit--namespace=kube-system pod kube-apiserver-k8s-master 查 看 
kube-apiserver Pod 的 配置 ，Volume 的 相关 部 分 如 图 9-5 所 示 。 


voLumeMounts: 
- mountPath: /etc/kubernetes 
name: k8s 
readOnly: 
- mountPath: /etc/ssl/certs 
name: certs 
- mountPath: /etc/pki 
name: pki 
dnsPolicy: ClusterFirst 
hostNetwork: 
nodeName: k8s-master 
restartPolicy: Always 
schedulerName: default-scheduler 
securityContext: {} 
terminationGracePeriodSeconds: 
tolerations: 
- effect: NoExecute 
operator: Exists 
voLumes: 
- hostPath: 
path: /etc/kubernetes 
name: k8s 
hostPath: 
path: /etc/ssl/certs 
name: certs 
hostPath: 
path: /etc/pki 
name: pki 





图 9-5 


这 里 定义 了 三 个 hostPath: volume k8s、certs 和 pki， 分 别 对 应 Host 目 
录 /etc/kubernetes、/etc/ssl/certs 和 /etc/pki。 


如 有 果 Pod 被 销毁 了 ，hostPath 对 应 的 目录 还 是 会 被 保留 ， 从 这 一 点 来 
看 ，hostPath 的 持久 性 比 emptyDir 强 。 不 过 一 旦 Host 裔 溃 ，hostPath 也 就 
无 法 访问 了 。 


接 下 来 我 们 将 学 习 有 具备 真正 持久 性 的 Volume。 


9.1.3 ”外 部 Storage Provider 


如 果 Kubernetes 部 署 在 诸如 AWS、GCE、Azure 等 公有 云 上 ， 可 以 
直接 使 用 云 便 盘 作为 Volume。 下 面 给 出 一 个 AWS Elastic Block Store 的 
例子 ， 如 图 9-6 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 

name: using-ebs 

spec: 

containers: 

- image: busybox 
name: using-ebs 
volumeMounts : 

- mountPath: /test-ebs 
name: ebs-volume 
volumes: 

- name: ebs-volume 


awsElasticBlockStore: 
volumeID: «volume-id» 
fsType: ext4 





图 9-6 


要 在 Pod 中 使 用 ESB volume， 必 须 先 在 AWS 中 创建 ， 然 后 通过 
volume-id 引 用 。 其 他 云 硬 盘 的 使 用 方法 可 参考 各 公有 云 厂 商 的 官方 文 
档 。 





Kubernetes Volume 也 可 以 使 用 主流 的 分 布 式 存储 ， 比 如 Ceph、 
GlusterFS 等 。 下 面 给 出 一 个 Ceph 的 例子 ， 如 图 9-7 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 
name: using-ceph 
spec: 
containers: 
- image: busybox 
name: using-ceph 
voLumeMounts: 
- name: ceph-volume 
mountPath: /test-ceph 
volumes: 
- name: ceph-volume 
cephfs: 
path: /some/path/in/side/cephfs 
monitors: 
secretFile: 





图 9-7 


Ceph 文 件 系 统 的 /some/pathyin/side/cephfs 目 录 被 mount 到 容器 路 
径 /test-ceph 。 


TR» TemptyDir&lhostPath, 3x: Volume2878 [f] ic CRT e SW Ae A IC 
赖 Kubernetes。Volume 的 底层 基础 设施 由 独立 的 存储 系统 管理 ， 与 
Kubernetes 集 群 是 分 离 的 。 数 据 被 持久 化 后 ， 即 使 整个 Kubernetes 崩 尝 也 
不 会 受 损 。 


当然 ， 运 维 这 样 的 存储 系统 通常 不 是 一 项 简单 的 工作 ， 特 别 是 对 可 
靠 性 、 可 用 性 和 扩展 性 有 较 高 要 求 的 时 候 。 








92  PersistentVolume & 
PersistentVolumeClaim 
Yohme 提 供 了 非常 好 的 数据 持 从 化 方案 ， 不 过 在 可 管理 性 上 还 有 


拿 前 面 的 AWS EBS 例 子 来 说 ， 要 使 用 Volume，Pod 必 须 事 先知 道 如 
Fi 


Dlr 


下 1 
(1) 当前 Volume 来 自 AWS EBS. 
(2) EBS Volume 已 经 提前 创建 ， 并 且 知 道 确 切 的 volume-id。 


Pod 通 常 是 由 应 用 的 开发 人 员 维 护 ， 而 Volume 则 通常 是 由 存储 系统 
的 管理 员 维 护 。 开 发 人 员 要 获得 上 面 的 信息 ， 要 么 询问 管理 员 ， 要 么 自 
己 就 是 管理 员 。 


这 样 就 带 来 一 个 管理 上 的 问题 : 应 用 开发 人 员 和 系统 管理 员 的 职 贡 
耘 合 在 一 起 了 。 如 条 系统 规模 较 小 或 者 对 于 开发 环境 ， 这 样 的 情况 还 可 
以 接受 ， 当 集群 规模 变 大 ， 特 别 是 对 于 生成 环境 ， 考 虑 到 效率 和 安全 
性 ， 这 就 成 了 必须 要 解决 的 问题 。 


Kubernetes 给 出 的 解决 方案 是 PersistentVolume 和 
PersistentVolumeClaim 。 


PersistentVolume (PV) 是 外 部 存储 系统 中 的 一 块 存储 空间 ， 由 管 
理 员 创建 和 维护 。 与 Volume 一 样 ，PV 具 有 持久 性 ， 生 命 周期 独立 于 
Pod. 











PersistentVolumeClaim (PVC) 是 对 PV 的 申请 (Claim) 。PVC 通 常 
由 普通 用 户 创 建 和 维护 。 需 要 为 Pod 分 配 存 储 资源 时 ， 用 户 可 以 创建 一 
个 PVC， 指 明 存 储 资源 的 容量 大 小 和 访问 模式 〈 比 如 只 读 ) 等 信息 ， 
Kubernetes 会 查找 并 提供 满足 条 件 的 PV。 


有 了 PersistentVolumeClaim， 用 户 只 需要 告诉 Kubernetes 需 要 什么 样 
的 存储 资源 ， 而 不 必 关 心 真正 的 空间 从 哪里 分 配 、 如 何 访问 等 底层 细节 
信息 。 这 些 Storage Provider 的 底层 信息 交 给 管理 员 来 处 理 ， 只 有 管理 员 
才 应 该 关心 创建 PersistentVolume 的 细节 信息 。 


Kubernetes 支 持 多 种 类 型 的 PersistentVolume， 比 如 AWS EBS, 
Ceph、NFS 等 ， 完 整 列 表 请 参考 


https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of- 
persistent-volumes. 


下 面 我 们 用 NFS 来 体会 PersistentVolume 的 使 用 方法 。 


9.2.1 NES PersistentVolume 


作为 准备 工作 ， 我 们 已 经 在 k8s-master 节 点 上 搭建 了 一 个 NFS 服 务 
器 ， 目 录 为 mfsdata， 如 图 9-8 所 示 。 


root@k8s-master :~# 
root@k8s-master:~# showmount -e 


Export list for k8s-master: 


/nfsdata * 
图 9-8 


下 面 创 建 一 个 PV mypv1， 配 置 文件 nfs-pv1.yml 如 图 9-9 所 示 。 





apiVersion: v1 
kind: PersistentVolume 
metadata: 
name: mypv1 
spec: 
capacity: 
storage: 1Gi 


accessModes: 


- ReadWriteOnce (2 
persistentVolumeReclaimPolicy: Recycle 
storageClassName: nfs 
nfs: 

path: /nfsdata/pv1 

server: 192.168.56.105 


图 9-9 





(D capacity 指 定 PV 的 容量 为 1GB。 


(2) accessModes 指 定 访问 模式 为 ReadWriteOnce， 支 持 的 访问 模式 有 
3 种 : ReadWriteOnce 表 示 PV 能 以 read-write 模 式 mount 到 单个 节点 ， 
ReadOnlyMany 表 示 PV 能 以 read-only 模 式 mount 到 多 个 节点 ， 
ReadWriteMany 表 示 PV 能 以 read-write 模 式 mount 到 多 个 节点 。 


(3 persistentVolumeReclaimPolicy 指 定 当 PV 的 回收 策略 为 Recycle， 
支持 的 策略 有 3 种 : Retain 表 示 需 要 管理 员 手 工 回 收 ; Recycle 表示 清除 
PV 中 的 数据 ， 效 果 相 当 于 执行 rm -rf/thevolume/*; Delete 表 示 删 除 
Storage Provider 上 的 对 应 存储 资源 ， 例 如 AWS EBS. GCE PD. Azure 
Disk. OpenStack Cinder Volume 等 。 


(4) ”storageClassName 指 定 PV 的 class 为 nfs。 相 当 于 为 PV 设置 了 一 个 
分 类 ，PVC 可 以 指定 class 申 请 相应 class 的 PV。 


©) 指定 PV 在 NFS 服 务 器 上 对 应 的 目录 。 


创建 mypvl1， 如 图 9-10 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f nfs-pv1.yml 
persistentvolume "mypv1" created 
ubuntu@k8s-master : ~$ 


ubuntuék8s-master:-$ kubectl get pv 
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON 
mypvi 1Gi RWO Recycle Available nfs 
ubuntu@k8s-master: ~$ 

图 9-10 





STATUS 为 Available， 表 示 mypv1 就 绪 ， 可 以 被 PVC 申 请 。 
接 下 来 创建 PVC mypvc1， 配 置 文件 nfs-pvcl.yml 如 图 9-11 所 示 。 


kind: PersistentVolumeClaim 
apiVersion: v1 
metadata: 
name: mypvci 
spec: 
accessModes: 


- ReadWriteOnce 


resources: 
requests: 
storage: 1Gi 
storageClassName: nfs 





图 9-11 


PVC 就 很 简单 了 ， 只 需要 指定 PV 的 容量 、 访 问 模 式 和 class 即 可 。 


创建 mypvc1， 如 图 9-12 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ kubectl apply -f nfs-pvc1.yml 


persistentvolumeclaim "mypvc1" created 

ubuntu@k8s-master :~$ 

ubuntu@k8s-master:~$ kubectl get pvc 

NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE 
mypvci Bound mypv1 1Gi RWO nfs 22s 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pv 


CAPACITY ACCESSMODES RECLAIMPOLICY [STATUS CLAIM STORAGECLASS REASON AGE 
Recycle Bound default/mypvci| nfs 6m 


图 9-12 


从 kubectl get pvc 和 kubectl get pv 的 输出 可 以 看 到 mypvcl 已 经 Bound 
到 mypv1， 申 请 成 功 。 


接 下 来 就 可 以 在 Pod 中 使 用 存储 了 ，Pod 配 置 文件 pod1.yml 如 图 9-13 
Ze 





kind: Pod 
apiVersion: v1 
metadata: 
name: mypod1 
spec: 
containers: 
- name: mypodi 
image: busybox 
args: 
- /bin/sh 
- -C 
- sleep 
volumeMounts : 
- mountPath: 
name: mydata 
volumes: 
- name: mydata 
persistentVolumeClaim: 
claimName: mypvc1 





图 9-13 


与 使 用 普通 Volume 的 格式 类 似 ， 在 volumes 中 通 
persistentVolumeClaim 指 定 使 用 mypvcl 申 请 的 Volume。 


创建 mypod1， 如 图 9-14 所 示 。 


ee 


ubuntu@k8s-master: ~$ 
ubuntu@k&s-master:~$ kubectl apply -f pod1.yml 
pod "mypod1" created 
ubuntu@k8s-master: ~$ 


ubuntu@k8s-master:~$ kubectl get pod -o wide 

READY STATUS RESTARTS AGE IP NODE 

1/1 Running 0 32s 10.244.4.60 k8s-node1 
ubuntu@k8s-master: ~$ 





图 9-14 


验证 PV 是 否 可 用 ， 如 图 9-15 所 示 。 


ubuntuek8s-master :~$ 
ubuntu@k8s-master:~$ kubectl exec mypod1 touch /mydata/hello 
ubuntuék8s master: ~$ 


ubuntu@k8s-master:~$ ls /nfsdata/pv1/ 
hello 
ubuntuek8s-master : ~$ 





图 9-15 


可 见 ， 在 Pod 中 创建 的 文件 /mydata/hello 确 实 已 经 保存 到 了 NES 服务 
器 目录 /nfsdata/pv1 中 。 


9.2/2 回收 PV 


当 不 需要 使 用 PV 时 ， 可 用 删除 PVC 回收 PYV， 如 图 9-16 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl delete pvc mypvci 
persistentvolumeclaim "mypvci" deleted 
ubuntuék8s master: ~$ 
ubuntuék8s-master:-$ kubectl get pod -o wide 
STATUS RESTARTS IP NODE 
0 


Running 25 10.244.4.60 — k8s-nodel 
ContainerCreating 0 <none> k8s-nodel 
ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get pv 


NAME CAPACITY ACCESSMODES RECLAIMPOLICY | STATUS CLAIM STORAGECLASS REA 
mypv1 1Gi RWO Recycle Released} default/mypvci nfs 


ubuntu@k8s-master: ~$ 
图 9-16 


当 PVC mypvcl 被 删除 后 ， 我 们 发 现 Kubernetes 启 动 了 一 个 新 Pod 
recycler-for-mypv1， 这 个 Pod 的 作用 就 是 清除 PV mypv1 的 数据 。 此 时 
mypv1 的 状态 为 Released， 表 示 已 经 解除 了 与 nypvcl 的 Bound， 正 在 清 
除数 据 ， 不 过 此 时 还 不 可 用 。 


当 数 据 清除 完毕 ，mypv1 的 状态 重新 变 为 Available， 此 时 可 以 被 新 





的 PVC 申 请 ， 如 图 9-17 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get pv 


CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS 
1Gi RWO Recycle Available nfs 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ ls /nfsdata/pv1/ 





图 9-17 
/nfsdata/pv1 中 的 hello 文 件 已 经 被 删除 了 。 


因为 PV 的 回收 策略 设置 为 Recycle， 所 以 数据 会 被 清除 ， 但 这 可 能 
不 是 我 们 想 要 的 结果 。 如 果 我 们 希望 保留 数据 ， 可 以 将 策略 设置 为 
Retain， 如 图 9-18 所 示 。 


apiVersion: v1 
kind: PersistentVolume 
metadata: 
name: mypvi 
spec: 
capacity: 
storage: 1G1 
accessModes: 


storageClassName: nfs 
nfs: 
path: /nfsdata/pv1 
server: 192.168.56.105 





图 9-18 


通过 kubectl apply 更 新 PV， 如 图 9-19 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl apply -f nfs-pv1.yml 
persistentvolume "mypvi" configured 
ubuntu@k8s-master : ~$ 


ubuntu@k8s-master:~$ kubectl get pv 


CAPACITY | ACCESSMODES [|RECLAIMPOLICY| STATUS CLAIM STORAGECLASS 
1Gi RWO Retain Available nfs 


ubuntu@k8s-master : ~$ 





图 9-19 


回收 策略 已 经 变 为 Retain， 通 过 下 面 的 步骤 验证 其 效果 ， 如 图 9-20 
所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl apply -f nfs-pvci.yml 


persistentvolumeclaim "mypvci" created 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl exec mypod1 touch /mydata/hello (2 

ubuntuék8s master: ~$ 

ubuntuék8s-master:-$ ls /nfsdata/pv1/ 

hello 

ubuntuék8s master: ~$ 

ubuntuék8s-master:-$ kubectl delete pvc mypvci 

persistentvolumeclaim "mypvci" deleted 

ubuntuék8s master: ~$ 

ubuntu@k8s-master:~$ kubectl get pv 

NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS 
mypv1 1Gi RWO Retain Released} default/mypvcl nfs 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE IP NODE 
mypod1 1/1 Running 0 46m 10.244.4.60 — k8s-nodel 
ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ ls /nfsdata/pv1/ 

hello 

ubuntu@k8s-master ; ~$ 





图 9-20 
CO 重新 创建 mypvc1。 
D 在 mypv1 中 创建 文件 hello。 
(8) mypv1 状 态 变 为 Released。 
(4) Kubernetes 并 没有 启动 Pod recycler-for-mypv1。 
(5) PV 中 的 数据 被 完整 保留 。 


里 然 mypv1 中 的 数据 得 到 了 保留 ， 但 其 PV 状态 会 一 直 处 于 
Released， 不 能 被 其 他 PVC 申 请 。 为 了 重新 使 用 存储 资源 ， 可 以 删除 并 
rat al 删除 操作 只 是 删除 了 PV 对 象 ， 存 储 空 间 中 的 数据 并 不 
会 补 删 除 。 


新 建 的 mypv1 状 态 为 Available， 如 图 9-21 所 示 ， 已 经 可 以 被 PVC 申 
VA o 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl delete pv mypv1 
persistentvolume "mypvi" deleted 
ubuntuek8s-master:-$ 

ubuntuek8s-master:-$ kubectl apply -f nfs-pvi.yml 


persistentvolume "mypvi" created 
ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get pv 
CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE 
Available 





Retain nfs 9s 


图 9-21 


PV 还 文 持 Delete 的 回收 策略 ， 会 删除 PV 在 Storage Provider 上 对 应 的 


存储 空间 。NFS 的 PV 不 支持 Delete， 支 持 Delete 的 Provider 有 AWS EBS, 
GCE PD. Azure Disk, OpenStack Cinder Volume 等 。 


9.2.3 ”PV 动态 供给 

在 前 面 的 例子 中 ， 我 们 提前 创建 了 PV， 然 后 通过 PVC 申 请 PV 并 在 
Pod 中 使 用 ， 这 种 方式 叫 作 静态 供给 (Static Provision) o 

与 之 对 应 的 是 动态 供给 (Dynamical Provision) ， 即 如 果 没 有 满足 
PVC 条 件 的 PV， 会 动态 创建 PV。 相 比 静 态 供 给 ， 动 态 供 给 有 明显 的 优 
A, 不 需要 提前 创建 PV， 减少 了 管理 员 的 工作 量 ， 效 率 高 。 


动态 供给 是 通过 StorageClass 实 现 的 ，StorageClass 定 义 了 如 何 创建 
PV， 下 面 给 出 两 个 例子 。 


(1) StorageClass standard， 如 图 9-22 所 示 。 





kind: StorageClass 
apiVersion: storage.k8s.io/v1 
metadata: 

name: standard 


provisioner: kubernetes.io/aws-ebs 
parameters: 
type: gp2 
reclaimPolicy: Retain 
图 9-22 





(2) StorageClass slow， 如 图 9-23 所 示 。 


kind: StorageClass 
apiVersion: storage.k8&s.i0/v1 
metadata: 

name: slow 


provisioner: kubernetes.10/aws-ebs 
parameters: 
type: 101 
zones: us-east-1d, us-east-1c 
iopsPerGB: 





图 9-23 


这 两 个 StorageClass 都 会 动态 创建 AWS EBS， 不 同 点 在 于 standard 创 
建 的 是 gp2 类 型 的 EBS， 而 slow 创 建 的 是 io1 类 型 的 EBS。 不 同类 型 的 EBS 
支持 的 参数 可 参考 AWS 官 方 文档 。 


StorageClass 文 持 Delete 和 Retain 两 种 reclaimPolicy， 默 认 是 Delete。 


与 之 前 一 样 ，PVC 在 申请 PV 时 ， 只 需要 指定 StorageClass、 容 量 以 
及 访问 模式 即 可 ， 如 图 9-24 所 示 。 


kind: PersistentVolumeClaim 
apiVersion: v1 
metadata: 
name: mypvci 
spec: 
accessModes: 





- ReadWriteOnce 
resources: 
requests: 
storage: 1Gi 
图 9-24 
除了 AWS EBS，Kubernetes 还 支持 其 他 多 种 动态 供给 PV 的 


Provisioner， 完 整 列表 请 参考 
https://kubernetes.io/docs/concepts/storage/storage-classes/#provisioner。 


9.3 一 个 数据 库 例子 


本 节 演 示 如 何 为 MySQL 数 据 库 提供 持久 化 存储 ， 步 又 为 : 
(1) 创建 PV 和 PVC。 

(2) 部 团 MySQL。 

(3) [MySQL I2 78 - 


(4) 模拟 节点 宕 机 故障 ，Kubernetes 将 MySQL 自动 迁移 到 其 他 节 


(5) 验证 数据 一 致 性 。 
首先 创建 PV 和 PVC， 配 置 说 明 如 下 。 


。 mysql-pv.yml 如 图 9-25 所 示 。 


apiVersion: v1 
kind: PersistentVolume 
metadata: 
name: mysql-pv 
spec: 
accessModes: 
- ReadWriteOnce 


capacity: 

storage: 1G1 
persistentVolumeReclaimPolicy: Retain 
storageCLassName: nfs 
nfs: 

path: /nfsdata/mysql-pv 

server: 192.168.56.105 





图 9-25 


e mysql-pvc.yml 如 图 9-26 所 示 。 


kind: PersistentVolumeClaim 
apiVersion: v1 
metadata: 
name: mysql-pvc 
spec: 
accessModes: 


- ReadWriteOnce 
resources: 
requests: 
storage: 1G1 
storageClassName: nfs 





图 9-26 


创建 mysql-pv 和 mysql-pvc， 如 图 9-27 所 示 。 


ubuntuek8s-master: ~$ 

ubuntuék8s-master:-$ kubectl apply -f mysql-pv.yml 
persistentvolume "mysql-pv" created 

ubuntuék8s master: ~$ 

ubuntu@k8s-master:~$ kubectl apply -f mysql-pvc.yml 
persistentvolumeclaim "mysql-pvc" created 
ubuntu@k8s-master : ~$ 


ubuntu@k8s-master:~$ kubectl get pv,pvc 
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLAS 
pv/mysql-pv 1Gi RWO Retain Bound default/mysql-pvc nfs 


NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE 
pvc/mysql-pvc Bound mysql-pv 1Gi RWO nfs 9s 
ubuntu@k8s-master:~$ 

图 9-27 


接 下 来 部 署 MySQL， 配 置 文件 如 图 9-28 所 示 。 





apiVersion: v1 
kind: Service 
metadata: 
name: mysql 
spec: 
ports: 
- port: 
selector: 
app: mysql 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 
name: mysql 
spec: 
selector: 
matchLabels : 
app: mysql 
template: 
metadata: 
labels: 
app: mysql 
spec: 
containers: 
- image: mysql:5.6 
name: mysql 
env: 
- name: MYSQL. ROOT. PASSWORD 
value: password 
ports: 
- containerPort: 
name: mysql 
volumeMounts : 


- name: mysql-persistent-storage 


mountPath: /var/lib/mysql 
volumes: 


- name: mysql-persistent-storage 


persistentVolumeClaim: 
claimName: mysql-pvc 





图 9-28 


PVC mysql-pvc Bound 的 PY mysql-pv 将 被 mount 到 MySQL 的 数据 目 


录 var/lib/mysql， 如 图 9-29 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl apply -f mysql.yml 
service "mysql" created 

deployment "mysql" created 


ubuntuék8s master : ~$ 

ubuntuék8s-master:-$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE IP NODE 
mysql-2150355289-p99h8 1/1 Running 0 15s 10.244.5.80 k8&s-node2 
ubuntu@k8s-master : ~$ 





图 9-29 


MySQL 被 部 普 到 k8s-node2， 下 面 通过 客户 端 访问 Service mysql, 4 
图 9-30 所 示 。 


kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql- 
client -- mysql-h mysql -ppassword 
ubuntuék8s -master: ~$ 


ubuntu@k8s-master:~$ kubectl run -it --rm --image-mysql:5.6 --restart-Never mysql-client -- mysql -h mysql -ppassword 
If you don't see a command prompt, try pressing enter. 





a 图 9-30 
更 新 数据 库 ， 如 图 9-31 所 示 。 


mysqL> 

mysql> use mysql (1 

Reading table information for completion of table and column names 
You can turn off this feature to get a quicker startup with -A 


Database changed 
mysql> create table my id( id int(4) ); 
Query OK, 0 rows affected (0.01 sec) 


mysql> insert my id values( 111 ); 
Query OK, 1 row affected (0.00 sec) 


1 row in set (0.00 sec) 





mysql» 


图 9-31 
CO 切换 到 数据 库 mysql。 
D 创建 数据 库 表 my_id。 
© 插入 一 条 数据 。 
由 确认 数据 已 经 写 入 。 
关闭 k8s-node2， 模 拟 节 点 宕 机 故障 ， 如 图 9-32 所 示 。 


root@k8s-node2 :~# 
root@k8s-node2:~# shutdown now 


Connection to 192.168.56.107 closed by remote host. 
Connection to 192.168.56.107 closed. 


图 9-32 





一 段 时 间 后 ，Kubernetes 将 MySQL 迁 移 到 k8s-node1， 如 图 9-33 所 


s-master:-$ kubectl get pod -o wide 
NAME READY STATUS RESTARTS AGE IP NODE 
mysql-2150355289-p13n5 1/1 Running 0 31s 10.244.4.66 k8s-node1 
mysql-2150355289-p99h8 1/1 Unknown 0 16m 10.244.5.80 k8s-node2 
ubuntu@k8s-master : ~$ 





[59-33 


验证 数据 的 一 致 性 ， 如 图 9-34 所 示 。 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword 
If you don't see a command prompt, try pressing enter. 


mysql> use mysql 
Reading table information for completion of table and column names 
You can turn off this feature to get a quicker startup with -A 


Database changed 


mysql> select * from my_id; 


1 row in set (0.00 sec) 





mysql> 


图 9-34 


MySQL 服 务 恢复 ， 数 据 也 完好 无 损 。 


9.4 小 结 


本 章 我 们 讨论 了 Kubernetes 如 何 管理 存储 资源 。 


emptyDir 和 hostPath 类 型 的 Volume 很 方便 ， 但 可 持久 性 不 强 ， 
Kubernetes 支 持 多 种 外 部 存储 系统 的 Volume。 


PV 和 PVC 分 离 了 管理 员 和 普通 用 户 的 职责 ， 更 适合 生产 环境 。 我 
们 还 学 习 了 如 何 通过 StorageClass 实 现 更 高 效 的 动态 供给 。 


最 后 ， 我 们 演示 了 如 何在 MySQL 中 使 用 PersistentVolume 实 现 数据 
持久 性 。 


310% Secret & Configmap 





应 用 局 动 过 程 中 可 能 需要 一 些 敏感 信息 ， 比如 访问 数据 库 的 用 户 
名 、 密 码 或 者 密 钥 。 将 这 些 信息 直接 保存 在 容器 镜像 中 显然 不 妥 ， 
Kubernetes 提 供 的 解决 方案 是 Secret。 


Secret 会 以 密 文 的 方式 存储 数据 ， 避 免 了 直接 在 配置 文件 中 保存 敏 
感 信息 。Secret 会 以 Volume 的 形式 被 mount 到 Pod， 容 器 可 通过 文件 的 方 
Rl UE 此 外 ， 容 器 也 可 以 环境 变量 的 方式 使 用 这 
些 数 据 。 








Secret 可 通过 命令 行 或 YAML 创 建 。 比 如 希望 Secret 中 包含 如 下 信 
息 : 用 户 名 admin、 密 码 123456。 


10.1 创建 Secret 


有 四 种 方法 创建 Secret: 


C12 通过 --from-literal: 


kubectl create secret generic mysecret - -from- 
literal-username-admin --from-literal-password-123456 





每 个 --from-literal 对 应 一 个 信息 条 目 
(2) 通过 --from-file: 


echo -n admin > ./username 

echo -n 123456 > ./password 

kubectl create secret generic mysecret --from-file-./username -- 
from-file-./password 


每 个 文件 内 容 对 应 一 个 信息 条 目 


(3) 通过 --from-env-file: 





cat «« EOF > env.txt 

username=admin 

password=123456 

EOF 

kubectl create secret generic mysecret --from-env-file=env.txt 





文件 env.txt 中 每 行 Key=Value 对 应 一 个 信息 条 目 


(4) 通过 YAML 配 置 文件 ， 如 图 10-1 所 示 。 


apiVersion: v1 
kind: Secret 
metadata: 

name: mysecret 
data: 

username: YWRtaW4= 


password: MTIzNDU2 


图 10-1 








文件 中 的 敏感 数据 必须 是 通过 base64 编 码 后 的 结果 ， 如 图 10-2 所 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ echo -n admin | base64 
YWRtaW4= 


ubuntu@k8s-master:~$ echo -n 123456 | base64 
MTIZNDU2 
ubuntu@k8s-master: ~$ 


图 10-2 





执行 kubectl apply 创 建 Secret， 如 图 10-3 所 示 。 


ubuntuék8s-master : ~$ 
ubuntuék8s-master:-$ kubectl apply -f mysecrete.yml 


secret "mysecret" created 
ubuntu@k8s-master : ~$ 





图 10-3 


10.2 查看 Secret 


通过 kubectl get secret 但 看 存在 的 secret， 如 图 10-4 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get secret mysecret 


NAME TYPE AGE 
mysecret Opaque 2 4m 
ubuntu@k8s-master : ~$ 

图 10-4 





显示 有 两 个 数据 条 目 ， 通 过 kubectl describe secret 查 看 条 目的 Key， 
如 图 10-5 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl describe secret mysecret 
Name: mysecret 

Namespace: default 

Labels: <none> 

Annotations: <none> 


Opaque 





图 10-5 


如 果 还 想 查 看 Value， 可 以 用 kubectl edit secret mysecret， 如 图 10-6 
所 示 。 


apiVersion: v1 
data: 
password: MTIzNDU2 
username: YWRtaW4- 
kind: Secret 
metadata: 
creationTimestamp: 2@17-10-10T07:16:21Z 


name: mysecret 
namespace: default 
resourceVersion: 
selfLink: /api/v1/namespaces/default/secrets/mysecret 
uid: eaeb498Q-ad8a-11e7-8f72-0800274451ad 
type: Opaque 





图 10-6 


然后 通过 base64 将 Value 反 编码 ， 如 图 10-7 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ echo -n MTIzNDU2 | base64 --decode 
123456ubuntu@k8s-master : ~$ 


ubuntuék8s-master:-$ echo -n YWRtaW4- | base64 --decode 
adminubuntuek8s-master : ~$ 
ubuntuék8s-master: ~$ 





图 10-7 


10.3 ”在 Pod 中 使 用 Secret 


Pod 可 以 通过 Volume 或 者 环境 变量 的 方式 使 用 Secret。 


10.3.1 Volume% IÑ 


Pod 的 配置 文件 如 图 10-8 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 

name: mypod 

spec: 
containers: 

- name: mypod 
image: busybox 
args: 

- /bin/sh 
- -C 


- sleep 10; touch /tmp/healthy; sleep 
volumeMounts : 
- name: foo 
mountPath: 2 
readOnly: 
volumes: 


- name: foo | 
secret: : 
secretName: mysecret 





图 10-8 


@ 定义 volume foo， 来 源 为 secret mysecret。 


(2) foo mount 到 容器 路 径 /etc/foo， 可 指定 读 写 权限 为 readOnly。 


创建 Pod 并 在 容器 中 读 取 Secret， 如 图 10-9 所 示 。 


ubuntukas- -master: -$ kubectl apply -f mypod.yml 
pod "mypod" created 

ubuntuék8s master: ~$ 

ubuntu@k8s-master:~$ kubectl exec -it mypod sh 
/ # 

/ € 1s /etc/foo 


password username 

/ # 

/ # cat /etc/foo/username 
admin/ # 

/ # cat /etc/foo/password 
123456/ # 

/ # 





图 10-9 


可 以 看 到 ，Kubernetes 会 在 指定 的 路 径 /etc/foo 下 为 每 条 敏感 数据 创 
建 一 个 文件 ， 文 件 名 就 是 数据 条 目的 Key， 这 里 是 /etc/foo/username 
和 /etc/foo/password，Value 则 以 明文 存放 在 文件 中 。 


我 们 也 可 以 自 定 义 存放 数据 的 文件 名 ， 比 如 将 配置 文件 改 为 如 图 
10-10 所 示 那 样 。 








apiVersion: v1 
kind: Pod 
metadata: 
name: mypod 
spec: 
containers: 
- name: mypod 
image: busybox 
args: 
- /bin/sh 
- =C 
- sleep 10; touch /tmp/healthy; sleep 
volumeMounts : 
- name: foo 
mountPath: 
readOnly: 
volumes: 
- name: foo 
secret: 
secretName: mysecret 
items: 
- key: username 
path: my-group/my-username 
- key: password 
path: my-group/my-password 





10-10 


这 时 数据 将 分 别 存放 在 /etc/foo/my-group/my-username 和 /etc/foo/my- 


group/my-password t . 


以 Volume 方 式 使 用 的 Secret 支 持 动 态 更 新 : Secret 更 新 后 ， 容 器 中 
的 数据 也 会 更 新 。 


”将 password 更 新 为 abcdef，base64 编 码 为 YWJjZGVm， 如 图 10-11 所 
示 。 


apiVersion: v1 
kind: Secret 
metadata: 

name: mysecret 


data: 
username: YWRtaW4= 


图 10-11 


更 新 Secret， 如 图 10-12 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl apply -f mysecrete.yml 
secret "mysecret" configured 

ubuntu@k8s-master : ~$ 








图 10-12 


儿 秒 钟 后 ， 新 的 password 会 同步 到 容 费 ， 如 图 10-13 所 示 。 


/ ož 

/ # cat /etc/foo/password 
123456/ # 

/ # 


/ # cat /etc/foo/password 
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10.3.2 ”环境 变量 方式 


通过 Volume 使 用 Secret， 容 器 必须 从 文件 读 取 数据 ， 稍 显 矿 烦 ， 
Kubernetes 还 支持 通过 环境 变量 使 用 Secret。 


Pod 配 置 文件 示例 如 图 10-14 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 

name: mypod 

spec: 

containers: 

- name: mypod 
image: busybox 
args: 

- /bin/sh 


-C 
sleep 10; touch /tmp/healthy; sleep 


name: SECRET_USERNAME 
valueFrom: 
secretKeyRef : 
name: mysecret 
key: username 
name: SECRET. PASSWORD 
valueFrom: 
secretKeyRef : 
name: mysecret 
key: password 





图 10-14 


创建 Pod 并 读 取 Secret， 如 图 10-15 所 示 。 


ubuntue@k8s-master :~ 

ubuntuék8s-master:-$ kubectl apply -f mypod-env.yml 
pod "mypod" created 

ubuntu@k8s-master: ~$ 

ubuntuék8s-master:-$ kubectl exec -it mypod sh 

/ # 


/ # echo $SECRET_USERNAME 
admin 

/ # 

/ # echo $SECRET_PASSWORD 
abcdef 

/ # 
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通过 环境 变量 SECRET_ USERNAME 和 SECRET PASSWORD 成 功 
读 取 到 Secret 的 数据 。 


需要 注意 的 是 ， 环 境 变量 读 取 Secret 很 方便 ， 但 无 法 文 撑 Secret 动 态 
更 新 。 


10.4 ConfigMap 


Secret 可 以 为 Pod 提 供 密 码 、Token、 私 钥 等 敏感 数据 ;对 于 一 些 非 
敏感 数据 ， 比 如 应 用 的 配置 信息 ， 则 可 以 用 ConfigMap。 


ConfigMap 的 创建 和 使 用 方式 与 Secret 非 常 类 似 ， 主 要 的 不 同 是 数据 
以 明文 的 形式 存放 。 


与 Secret 一 样 ，ConfigMap 也 支持 四 种 创建 方式 : 





(1) 通过 --from-literal: 


kubectl create configmap myconfigmap --from-literal-configi-xxx-- 
from-literal-config2-yyy 





每 个 --from-literal 对 应 一 个 信息 条 目 。 
(2) 通过 --from-file: 
echo -n xxx > ./configi 
echo -n yyy > ./config2 


kubectl create configmap myconfigmap --from-file=./configi -- 
from-file-./config2 


每 个 文件 内 容 对 应 一 个 信息 条 目 。 





(3) 通过 --from-env-file: 


cat «« EOF > env.txt 

configi-xxx 

config2-yyy 

EOF 

kubectl create configmap myconfigmap --from-env-file=env.txt 





文件 env.txt 中 每 行 Key=Value 对 应 一 个 信息 条 目 。 


(4) 通过 YAML 配 置 文件 ， 如 图 10-16 所 示 。 文 件 中 的 数据 直接 以 
明文 输入 。 


apiVersion: v1 
kind: ConfigMap 
metadata: 

name: myconfigmap 


data: 
configl: xxx 
config2: yyy 





图 10-16 


与 Secret 一 样 ，Pod 也 可 以 通过 Volume 或 者 环境 变量 的 方式 使 用 


Secret. 


(1) Volume 方 式 如 图 10-17 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 

name: mypod 

spec: 

containers: 

- name: mypod 
image: busybox 
args: 

- /bin/sh 


- -c 


- sleep 10; touch /tmp/healthy; sleep 
volumeMounts : 
- name: foo 
mountPath: 
readOnly: 
volumes: 
- name: foo 
configMap: 
name: myconfigmap 
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(2) 环境 变量 方式 如 图 10-18 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 

name: mypod 

spec: 

containers: 

- name: mypod 
image: busybox 
args: 

- /bin/sh 


-C 
sleep 10; touch /tmp/healthy; sleep 


name: CONFIG 1 
valueFrom: 
configMapKeyRef : 
name: myconfigmap 
key: configi 
name: CONFIG_2 
valueFrom: 
configMapKeyRef : 
name: myconfigmap 
key: config2 
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大 多 数 情况 下 ， 配 置信 息 都 以 文件 形式 提供 ， 所 以 在 创建 
ConfigMap 时 通常 采用 --from-file 或 YAML 方 式 ， 读 取 ConfigMap 时 通常 
采用 Volume 方 式 。 比 如 给 Pod 传 递 如 何 记录 日 志 的 配置 信息 ， 如 图 10-19 
DE 


class: lLogging.handlers.RotatingFileHandler 
formatter: precise 


Level: INFO 
filename: %hostname-%timestamp. log 


图 10-19 





可 以 采用 -from- -file 形 式 ， 将 其 保存 在 文件 logging.conf 中 ， 然 后 执 
行 命令 


kubectl create configmap myconfigmap --from-file-./logging.conf 


如 果 采 用 YAML 配 置 文件 ， 其 内 容 则 如 图 10-20 所 示 。 


apiVersion: v1 
kind: ConfigMap 
metadata: 

name: myconfigmap 
data: 


logging.conf: | 
class: logging.handlers.RotatingFileHandler 
formatter: precise 
level: INFO 
filename: %hostname-%timestamp. log 





图 10-20 


注意 ， 别 漏 写 了 Key logging.conf 后 面 的 | 符号 。 


创建 并 查看 ConfigMap， 如 图 10-21 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f myconfigmap.yml 
configmap "myconfigmap" created 

ubuntuék8s master : ~$ 

ubuntu@k8s-master:~$ kubectl get configmap myconfigmap 

NAME DATA AGE 

myconfigmap 1 12s 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl describe configmap myconfigmap 
Name: myconfigmap 

Namespace: default 

Labels: <none> 

Annotations: kubectl.kubernetes.io/last-applied-configuration-["apiVersion" : "v1" 





e-%timestamp... 


Data 


logging.conf: 

class: lLogging.handlers.RotatingFileHandler 
formatter: precise 

level: INFO 

filename: %hostname-%timestamp. log 


Events: <none> 
ubuntu@k8s-master : ~$ 





图 10-21 


在 Pod 中 使 用 此 ConfigMap， 配 置 文件 如 图 10-22 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 

name: mypod 

spec: 

containers: 

- name: mypod 
image: busybox 
args: 

- /bin/sh 


- -C 


- sleep 10; touch /tmp/healthy; sleep 
volumeMounts : 
- name: foo 
mountPath: 
volumes: 
- name: foo 
configMap: 
name: myconfigmap 
items: 
- key: logging.conf 
path: myapp/logging.conf 








图 10-22 
(D 在 volume 中 指定 存放 配置 信息 的 文件 相对 路 径 为 


myapp/logging.conf. 
(2) 将 volume mount 到 容器 的 /etc 目 录 。 


创建 Pod 并 读 取 配置 信息 ， 如 图 10-23 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl apply -f mypod.yml 
pod "mypod" created 

ubuntuék8s master : ~$ 

ubuntuék8s-master:-$ kubectl exec -it mypod sh 
/ # 


/ € cat /etc/myapp/logging.conf 

class: lLogging.handlers.RotatingFileHandler 
formatter: precise 

LeveL: INFO 

filename: %hostname-%timestamp. log 

/ # 





图 10-23 


配置 信息 已 经 保存 到 /etc/myapp/logging.conf 文 件 中 。 与 Secret 一 
样 ，Volume 形 式 的 ConfigMap 也 支持 动态 更 新 ， 留 给 大 家 自己 实践 。 


T 
10.5 “pa 
本 章 我 们 学 习 了 如 何 向 Pod 传 递 配 置信 息 。 如 果 信 息 需 要 加 密 ， 可 
使 用 Secret; 如 果 是 一 般 的 配置 信息 ， 则 可 使 用 ConfigMap。 


Secret 和 ConfigMap 文 持 四 种 定义 方法 。Pod 在 使 用 它们 时 ， 可 以 选 
择 Volume 方 式 或 环境 变量 方式 ， 不 过 只 有 Volume 方 式 支 持 动态 更 新 。 
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für 


本 章 我 们 将 学 习 Helm Kubernetes 的 包 管 理 器 。 


每 个 成 功 的 软件 平台 都 有 一 个 优秀 的 打包 系统 ， 比 如 Debian、 
Ubuntu 的 apt，Red Hat、CentOS 的 yum。Helm 则 是 Kuberetes 上 的 包 管 
JH dg 


本 章 我 们 将 讨论 为 什么 需要 Helm、 它 的 架构 和 组 件 ， 以 及 如 何 使 
用 Helm 。 





11.1 Why Helm 


Helm!) ccf te Y fr qui? 为 什么 Kubernetes 需 要 Helm? 


答案 是 : Kubernetes 能 够 很 好 地 组 织 和 编排 容器 ， 但 它 缺 少 一 个 更 
高 层次 的 应 用 打包 工具 ， 而 Helm 就 是 来 干 这 件 事 的 。 


先 来 看 个 例子 。 
比如 对 于 一 个 MySQL 服 务 ，Kubernetes 需 要 部 署 下 面 这 些 对 象 : 
(1) Service， 让 外 界 能 够 访问 到 MySQL， 如 图 11-1 所 示 。 


apiVersion: v1 
kind: Service 
metadata: 
name: my-mysql 
labels: 
app: my-mysql 
spec: 


ports: 
- name: mysql 

port: 

targetPort: mysql 
selector: 

app: my-mysql 


图 11-1 





(2) Secret， 定 义 MySQL 的 密码 ， 如 图 11-2 所 示 。 


apiVersion: vi 
kind: Secret 
metadata: 
name: my-mysql 
labels: 
app: my-mysql 
: Opaque 


mysql-root-password: 
mysql-password: 





图 11-2 


(3) PersistentVolumeClaim， 为 MySQL 申 请 持久 化 存储 空间 ， 如 
图 11-3 所 示 。 


kind: PersistentVolumeClaim 
apiVersion: v1 
metadata: 
name: my-mysql 
labels: 
app: my-mysql 


spec: 
accessModes: 


resources: 


requests: 
storage: 


图 11-3 


(4) Deployment， 部 署 MySQL ” Pod， 并 使 用 上 面 的 这 些 支持 对 
象 ， 如 图 11-4 所 示 。 





apiVersion: extensions/vibetal 
kind: Deployment 
metadata: 
name: my-mysqL 
labels: 
app: my-mysql 
spec: 
tempLate: 
metadata: 
labels: 
app: my-mysql 
spec: 
containers: 
- name: my-mysql 
image: 
env: 
- name: MYSQL. ROOT. PASSWORD 
valueFrom: 
secretKeyRef : 
name: my-mysql 
key: mysql-root-password 
name: MYSQL_PASSWORD 
valueFrom: 
secretKeyRef : 
name: my-mysql 
key: mysql-password 
name: MYSQL_USER 
value: 
name: MYSQL_DATABASE 
value: 
ports: 
- name: mysql 
containerPort: 
voLumeMounts : 
- name: data 
mountPath: /var/lib/mysql 
volumes: 
- name: data 
persistentVolumeClaim: 
claimName: my-mysql 





图 11-4 


我 们 可 以 将 上 面 这 些 配置 保存 到 对 象 各 自 的 文件 中 ， 或 者 集中 写 进 
一 个 配置 文件 ， 然 后 通过 kubectl apply -f 部 署 。 


到 目前 为 止 ，Kubernetes 对 服务 的 部 署 文 持 得 都 挺 好 ， 如 果 应 用 只 
由 一 个 或 几 个 这 样 的 服务 组 成 ， 上 面 的 部 署 方式 完全 足够 了 。 


(Exe, "WARD HT AEN E WIR ARTA HDA, ZELDA FS A SBT RE 
多 达 十 个 甚至 几 十 上 百 个 ， 这 种 组 织 和 管理 应 用 的 方式 就 不 好 使 了 : 


C1) 很 难 管理 、 编 辑 和 维护 如 此 多 的 服务 。 每 个 服务 都 有 符 干 配 
置 ， 缺 乏 一 个 更 高 层次 的 工具 将 这 些 配置 组 织 起 来 。 


(2) 不 容易 将 这 些 服务 作为 一 个 整体 统一 发 布 。 部 嗜 人 员 需 要 首 
先 理解 应 用 都 包含 哪些 服务 ， 然 后 按照 逻辑 顺序 依次 执行 kubectl 
n. 即 缺 少 一 种 工具 来 定义 应 用 与 服务 ， 以 及 服务 与 服务 之 间 的 依 
WR 


(3) 不 能 高 效 地 共享 和 重用 服务 。 比 如 两 个 应 用 都 要 用 到 MySQL 
服务 ， 但 配置 的 参数 不 一 样 ， 这 两 个 应 用 只 能 分 别 复制 一 套 标准 的 
MySQL 配 置 文件 ， 修 改 后 通过 kubectl apply 部署。 也 就 是 说 ， 不 支持 参 
RU AC Ss AS ALES o 


(4) 不 文 持 应 用 级 别 的 版 本 管理 。 虽 然 可 以 通过 kubectl ^ rollout 
undo 进 行 回 深 ， 但 这 只 能 针对 单个 Deployment， 不 支持 整个 应 用 的 回 
R. 











(50 ASCH ABS MAHARSI SE. aE n SEXE TE X. 
的 账号 访问 MySQL 。 虽 然 Kubernetes 有 健康 检查 ， 但 那 是 针对 单个 容 
器 ， 我 们 需要 应 用 《服务 ) 级 别 的 健康 检查 。 


Helm 能 够 解决 上 面 这 些 问 题 ，Helm 帮 助 Kubernetes 成 为 微服 务 架 构 
应 用 理想 的 部 署 平台 。 








11.2 Helm2Zf/j 


在 实践 之 前 ， 我 们 先 来 看 看 Helm 的 架构 。 


Helm 有 两 个 重要 的 概念 : chart 和 release。 


chart 是 创建 一 个 应 用 的 信息 集合 ， 包 括 各 种 Kubernetes 对 象 的 配置 
模板 、 参 数 定 义 、 依 赖 关 系 、 文 档 说 明 等 。chart 是 应 用 部 署 的 目 包 
含 逻 辑 单元 。 可 以 将 chart 想 象 成 apt、yum 中 的 软件 安装 包 。 
release 是 chart 的 运行 实例 ， 代 表 了 一 个 正在 运行 的 应 用 。 当 chart 被 
安装 到 Kubernetes 集 群 ， 就 生成 一 个 release。chart 能 够 多 次 安装 到 
同一 个 集群 ， 每 次 安装 都 是 一 个 release。 


Helm 是 包 管 理工 具 ， 这 里 的 包 就 是 指 的 chart。Helm 能 够 : 








从 零 创建 新 chart。 

与 存储 chart 的 仓库 交互 ， 拉 取 、 保 存 和 更 新 chart。 
在 Kubernetes 集 群 中 安装 和 和 仓 载 release。 

更 新 、 回 深 和 测试 release。 


Helm 包 含 两 个 组 件 : Helm 客 户 端 和 Tiller 服 务 器 ， 如 图 11-5 所 示 。 





Helm | gRPC | Till ) Kube 
Client | 2) API 


Kubernetes 





图 11-5 
Helm 客 户 端 是 终端 用 户 使 用 的 命令 行 工 具 ， 用 户 可 以 : 
。 在 本 地 开发 chart。 


e 管理 chart 仓 库 。 


与 Tiller 服 务 右 交互 。 


在 远程 Kubernetes 集 群 上 安装 chart。 
e 查看 release 信 息 。 
e JH EXE S A Mrelease. 


Tiller 服 务 器 运行 在 Kubernetes 集 群 中 ， 它 会 处 理 Helm 客 户 端 的 请 
求 ， 与 Kubernetes API Server 交 互 。Tiller 服 务 器 负责 : 


监听 来 自 Heljm 客 户 端的 请 求 。 

通过 chart 构 建 release。 

在 Kubernetes 中 安装 chart， 并 跟踪 release 的 状态 。 
通过 API Server 升 级 或 旬 载 已 有 的 release。 


简单 地 讲 ，Helm 客 户 端 负责 管理 chart，Tiller 服 务 器 负责 管理 
release。 


11.3 ”安装 Helm 
本 区 我们 将 依次 安装 Helm 客 户 端 和 Tiller 服 务 器 ， 


11.3.1 Helm AZ F ži 





通常 ， 我 们 将 Helm 客 户 端 安装 在 能 够 执行 kubect 命 令 的 节点 上 ， 只 
需要 下 面 一 条 命令 : 


curl https://raw.githubusercontent.com/kubernetes/helm/master/scr 


结果 如 图 11-6 所 示 。 





ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash 
% Total % Received % Xferd Average Speed Time Time Time Current 
Dload Upload Total Spent Left Speed 
100 6329 100 6329 0 0 4179 0 0:00:01 0:00:01 --:--:-- 4180 


Downloading https://kubernetes-helm.storage.googleapis.com/helm-v2.6.2-linux-amd64.tar.gz 
Preparing to install into /usr/local/bin 

helm installed into /usr/local/bin/helm 

Run 'helm init' to configure helm. 

ubuntuék8s-master:-$ 





图 11-6 


执行 helm version 验 证 ， 如 图 11-7 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ helm version 
Client: &version.Version{SemVer: "v2.7.0", GitCommit:"08c1144f5eb3e3b636 


d9775617287cc26e53dba4", GitTreeState:"clean"} 
Error: cannot connect to Tiller 
ubuntu@k8s-master : ~$ 





图 11-7 
目前 只 能 查看 到 客户 端的 版 本 ， 服 务 器 还 没有 安装 。 


helm 有 很 多 子 命令 和 参数 ， 为 了 提高 使 用 命令 行 的 效率 ， 通 常 建议 
安装 helm 的 bash 命 令 补 全 脚本 ， 方 法 如 下 : 


helm completion bash > .helmrc echo "source .helmrc" >> .bashrc 


重新 登录 后 就 可 以 通过 Tab 键 补 全 helm 子 命令 和 参数 了 ， 如 图 11-8 
所 示 。 


helm 
get install repo status version 
history Lint reset template 
home list rollback test 
init package search upgrade 
inspect plugin serve verify 
ubuntu@k8s-master:~$ helm install -- 
i --name= --tls-ca-cert- 


--namespace- --tls-cert- 


--name-template- --tls-key- 
--no-hooks --tls-verify 
--replace --values- 
--repo- --verify 
--set- --version- 
--tiller-namespace= --wait 
--timeout= 

--tls 





ubuntuek8s -master : ~$ 
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11.3.2 Tiller/] 4 2 


Tiller 服 务 器 安装 非常 简单 ， 只 需要 执行 helm init 即 可 ， 如 图 11-9 所 
ZN o 
ubuntuék8s-master : ~$ 


ubuntu@k8s-master:~$ helm init 
$HELM HOME has been configured at /home/ubuntu/.helm. 


Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster. 
Happy Helming! 
ubuntuek8s-master : ~$ 





图 11-9 


Tiller 本 身 也 是 作为 容器 化 应 用 运行 在 Kubermetes Cluster 中 的 ， 如 图 
11-10 所 示 。 





ubuntu@k8s-master :~ 
ubuntuék8s-master:-$ kubectl get --namespace=kube-system svc tiller-deploy 
NAME CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
tiller-deploy 10.98.124.71 <none> 44134/TCP im 
ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ kubectl get --namespace-kube-system deployment tiller-deploy 
NAME DESIRED CURRENT UP-TO-DATE AVATLABLE AGE 
1 


tiller-deploy T 1 1 1m 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace-kube-system pod tiller-deploy-1936853538-c8sfp 
NAME READY STATUS RESTARTS AGE 
tiller-deploy-1936853538-c8sfp 1/1 Running 0 2m 


ubuntu@k8s-master: ~$ 





图 11-10 
可 以 看 到 Tiller 的 Service、Deployment 和 Pod。 


MÆ, hem version 已 经 能 够 查看 到 服务 器 的 版 本 信息 了 ， 如 图 11- 
11 所 示 。 


root@k8s-master:~# helm version 
Client: &version.Version{SemVer: "v2.7.0", GitCommit:"08c1144f5eb3e3b6364d9775617287cc 


26e53dba4", GitTreeState:"clean"} 
Server: &version.Version{SemVer:"v2.7.0", GitCommit:"08c1144f5eb3e3b636d9775617287cc 
26e53dba4", GitTreeState:"clean"} 





图 11-11 


11.4 使 用 Helm 


Helm 安 装 成 功 后 ， 可 执行 helm search 查 看 当前 可 安装 的 chart， 如 图 


11-12 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ helm search 
NAME 

local/cool-chart 
stable/acs-engine-autoscaler 
stable/artifactory 
stable/aws-cluster-autoscaler 
stable/buildkite 
stable/centrifugo 
stable/chaoskube 
stable/chronograf 
stable/cluster-autoscaler 
stable/cockroachdb 
stable/concourse 
stable/consul 

stable/coredns 
stable/coscale 
stable/dask-distributed 
stable/datadog 
stable/dokuwiki 
stable/drupal 
stable/etcd-operator 


E 


0 
0 
0 
0 
0 
0 
0 
0 
.0 
.0 
2 
.0 
.0 
.0 
.0 
.0 


© 
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这 个 列表 很 长 ， 这 里 只 截取 了 一 部 分 。 大 家 不 茶会 问 ， 这 些 chart 都 


是 从 哪里 来 的 ? 


前 面 说 过 ，Helm 可 以 像 apt 和 yum 管 理 软件 包 一 样 管理 chart。apt 和 
yum 的 软件 包 和 存放 在 仓库 中 ， 同 样 的 ，Helm 也 有 仓库 ， 如 图 11-13 所 





ZN o 


ubuntu@k8s-master:~$ 


A Helm chart for Kubernetes 
Scales worker nodes within agent pools 


Universal Repository Manager supporting all maj... 


SION DESCRIPTION 
T 


Scales worker nodes within autoscaling groups. 
Agent for Buildkite 
Centrifugo is a real-time messaging server. 


Chaoskube periodically kills random pods in you... 
Open-source web application written in Go and R... 


Scales worker nodes within autoscaling groups. 


CockroachDB is a scalable, survivable, strongly... 


Concourse is a simple and scalable CI system. 


Highly available and distributed service discov... 
CoreDNS is a DNS server that chains middleware ... 


CoScale Agent 
Distributed computation in Python 
DataDog Agent 


DokuWiki is a standards-compliant, simple to us... 
One of the most versatile open source content m... 





CoreOS etcd-operator Helm chart for Kubernetes 


图 11-12 


ubuntuék8s-master:-$ helm repo list 


NAME URL 


stable https://kubernetes-charts.storage.googleapis.com 
local http://127.0.0.1:8879/charts 
ubuntu@k8s-master: ~$ 


Helm 安 装 时 已 经 默认 配置 好 了 两 个 仓库 : stable 和 1local。stable 是 官 








图 11-13 


方 仓库 ，local 是 用 户 存 放 自 己 开发 的 chart 的 本 地 仓库 。 


helm search 会 显示 chart 位 于 哪个 仓库 ， 比 如 localcool-chart 和 


stable/acs-engineautoscaler. 


用 户 可 以 通过 helm repo addZs/n: Weg. Muha 
库 ， 仓 库 的 管理 和 维护 方法 请 参考 官网 文档 https://docs.helm.sh。 


与 apt 和 和 yum 一 样 ，helm 也 支持 关键 字 搜 索 ， 如 图 11-14 所 示 。 包 括 
is aie ne resect 
列 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ helm search mysql 
VERSION DESCRIPTION 
0.3.0 Fast, reliable, scalable, and easy to use open-... 
free, fully compatible, enhanced, open source d... 








9.3.0 
stable/gcloud-sqlproxy 20.2.0 Google Cloud SQL Proxy 
2.0.0 


stable/mariadb 
ubuntu@k8s-master : ~$ 


Fast, reliable, scalable, and easy to use open-... 





图 11-14 
安装 chart 也 很 简单 ， 执 行 如 下 命令 就 可 以 安装 MySQL。 
helm install stable/mysql 


a 如 果 看 到 如 图 11-15 所 示 的 报错 ， 通 常 是 因为 Tiller 服 务 器 的 权限 不 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ helm install stable/mysql 


Error: no available release name found 
ubuntu@k8s-master:~$ 





图 11-15 


执行 如 下 命名 添加 权限 : 


kubectl create serviceaccount --namespace kube-system tiller 
kubectl create clusterrolebinding tiller-cluster-rule -- 
clusterrole=cluster-admin --serviceaccount=kube-system: tiller 
kubectl patch deploy --namespace kube-system tiller-deploy - 
p '{"spec":{"template": {"spec": {"serviceAccount":"tiller"}}}}' 


然后 再 次 执行 下 面 的 命令 ， 结 末 如 图 11-16 所 示 。 


helm install stable/mysql 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ helm install stable/mysql 
NAME : fun-zorse (1 

LAST DEPLOYED: Tue Oct 17 11:34:55 2017 
NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 


CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
fun-zorse-mysql 10.108.23.5 «none» 3306/TCP Qs 


==> vibetal/Deployment 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE 
fun-zorse-mysql 1 1 1 


==> v1/Secret 
NAME TYPE DATA AGE 
fun-zorse-mysql Opaque 2 1s 


==> v1/PersistentVolumeClaim 
NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE 
fun-zorse-mysql Pending 1s 


a 
NOTES: 2 

MySQL can be accessed via port 3306 on the following DNS name from within your cluster: 
fun-zorse-mysql.default.svc.cluster.local 


To get your root password run: 
kubectl get secret --namespace default fun-zorse-mysql -o jsonpath="{.data.mysql-root-passwor 
To connect to your database: 
1. Run an Ubuntu pod that you can use as a client: 
kubectl run -i --tty ubuntu --image-ubuntu:16.04 --restart=Never -- bash -il 
2. Install the mysql client: 
$ apt-get update && apt-get install mysql-client -y 


3. Connect using the mysql cli, then provide your password: 
$ mysql -h fun-zorse-mysql -p 
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输出 分 为 三 部 分 : 


(D chart 本 次 部 署 的 描述 信息 。 


e NAME 是 release 的 名 字 ， 因 为 我 们 没 用 -n 参 数 指定 ， 所 以 Helm 随 机 
生成 了 一 个 ， 这 里 是 fun-zorse。 

e NAMESPACE 是 release 部 署 的 namespace， 默 认 是 default， 也 可 以 通 
过 --namespace 指 定 。 

e STATUS 为 DEPLOYED， 表 示 已 经 将 chart 部 署 到 集群 。 


© 当前 release 包 含 的 资源 : Service、Deployment、Secret 和 
PersistentVolumeClaim， 其 名 字 都 是 fun-zorse-mysql， 命 名 的 格式 为 
ReleasName-ChartName。 


e NOTES 部 分 显示 的 是 release 的 使 用 方法 ， 比 如 如 何 访问 





Service、 如 何 获 取 数 据 库 密码 以 及 如 何 连接 数据 库 等 。 
通过 kubectl get 可 以 查看 组 成 release 的 各 个 对 象 ， 如 图 11-17 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get service fun-zorse-mysql 

NAME CLUSTER-IP EXTERNAL-IP PORTCS) AGE 

fun-zorse-mysql 10.108.23.5 | «none» 3306/TCP 15m 

ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get deployment fun-zorse-mysql 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
fun-zorse-mysql 1 1 1 0 15m 
ubuntuék8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get pod fun-zorse-mysql-2959529493-hfqit 

NAME READY STATUS RESTARTS AGE 
fun-zorse-mysql-2959529493-hfqit 0/1 Pending 0 15m 
ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get pvc fun-zorse-mysql 

NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE 
fun-zorse-mysql Pending 15m 
ubuntu@k8s-master : ~$ 
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因为 我 们 还 没有 准备 PersistentVolume， 所 以 当前 release 还 不 可 用 。 


helm list ROARS release, helm delete 可 以 删除 release， 如 图 
11-18 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ helm list 

NAME REVISION UPDATED STATUS CHART 

fun-zorse 1 Tue Oct 17 11:34:55 2017 DEPLOYED mysql-0.3.0 default 





ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ helm delete fun-zorse 


release "fun-zorse" deleted 
ubuntu@k8s-master : ~$ 
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Helm 的 使 用 方法 像 极 了 apt 和 yum， 用 Helm 来 管理 Kubernetes 应 用 非 
第 方便 。 


11.5 chartit f£ 


chart 是 Helm 的 应 用 打包 格式 。chart 由 一 系列 文件 组 成 ， 这 些 文 件 
描述 了 Kubernetes 部 蜀 应 用 时 所 需要 的 资源 ， 比 如 Service、 
Deployment、PersistentVolumeClaim、Secret、ConfigMap 等 。 


单个 的 chart 可 以 非常 简单 ， 只 用 于 部 署 一 个 服务 ， 比 如 
Memcached。chart 也 可 以 很 复杂 ， 部 署 整个 应 用 ， 比 如 包含 HTTP 
Servers、Database、 消 息 中 间 件 、Cache 等 。 


chart 将 这 些 文件 放置 在 预定 义 的 目录 结构 中 ， 通 第 整个 chart 被 打 成 
tar 包 ， 而 且 标 注 上 版 本 信息 ， 便 于 Helm 部 署 。 


下 面 我 们 将 详细 讨论 chart 的 目录 结构 以 及 包含 的 各 类 文件 。 


11.5.1 chart H Zt 


以 前 面 MySQL ”chart 为 例 。 一 旦 安装 了 某 个 chart， 我 们 就 可 以 在 
一 /.helm/cache/archive 中 找到 chart 的 tar 包 ， 如 图 11-19 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ ls ~/.helm/cache/archive 


mysql-0.3.0.tgz 
ubuntu@k8s-master:~$ 
图 11-19 





解压 后 ，MySQL chart 目 录 结 构 如 图 11-20 所 示 。 


ubuntuék8s master : ~$ 
ubuntu@k8s-master:~$ tree mysql 
mysql 

| 一 Chart.yaml 

H—— README .md 

| 一 templates 

| configmap.yaml 
| deployment. yam1 
| _helpers.tpl 

| NOTES.txt 

| pvc.yaml 

| secrets. yamL 

| svc.yaml 

L— values.yaml 


1 directory, 10 files 
ubuntu@k8s-master : ~$ 
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QD ENSE (不 带 版 本 信息 ) ， 这 里 是 mysql， 包 含 如 
下 内 容 。 


(1) Chart.yaml 





YAML 文 件 ， 描 述 chart 的 概要 信息 ， 如 图 11-21 所 示 。 


description: Fast, reliable, scalable, and easy to use open-source relational database 
system. 

engine: gotpl 

home: https://www.mysql.com/ 

icon: https://www.mysql.com/common/logos/logo-mysql-170x115.png 

keywords: 

- mysql 

- database 

- sql 


maintainers: 

- email: viglesias@google.com 
name: Vic Iglesias 

name: mysql 


sources: 

- https://github.com/kubernetes/charts 

- https://github.com/docker-library/mysql 
version: 0.3.0 





图 11-21 
name 和 和 version 是 必 填 项 ， 其 他 都 是 可 选项 。 
(2) README.md 


Markdown 格 式 的 README 文 件 ， 相 当 于 chart 的 使 用 文档 ， 此 文件 
为 可 选 ， 如 图 11-22 所 示 。 


) is one of the most popular database servers in the world. Notable users includ 


This chart bootstraps a single node MySQL deployment on a [ 
Pr 


Kubernetes 1.64 with Beta APIs enabled 
- PV provisioner support in the underlying infrastructure 


To install the chart with the release name ‘my-release : 
Lele r 
$ helm install --name my-release stable/mysql 
The command deploys MySQL on the Kubernetes cluster in the default configuration. The [configuration] ( 


By default a random password will be generated for the root user. If you'd like to set your own password 
in the values.yaml. 


You can retrieve your root password by running the following command. Make sure to replace [YOU | 1383 | 


printf $(printf '\%o' "kubectl get secret [YOUR RELEASE. NAME]-mysql -o jsonpath="{.data.mysql-root-pa| 


pil: List all releases using ‘helm list 


To uninstall/delete the ^my-release deployment: 
bash 
$ helm delete my-release 
The command removes all the Kubernetes components associated with the chart and deletes the release. 
+ ( Wigurat 
The following tables lists the configurable parameters of the MySQL chart and their default values. 
Parameter Description Default 
imageTag mysql image tag. Most recent release 
imagePullPolicy Image pull policy IfNotPresent 
mysqlRootPassword Password for the ‘root’ user. nil 
mysqlUser Username of new user to create. nil 


mysqlPassword Password for the new user. nil 
mysqlDatabase Name for new database to create. nil 


图 11-22 





(3) LICENSE 
文本 文件 ， 描述 术 chart 的 许可 信息 sy 9 此 文件 为 可 选 。 


(4) requirements.yaml 


chart 可 能 依赖 其 他 的 chart， 这 些 依赖 天 系 可 通过 requirements.yaml 
指定 ， 如 图 11-23 所 示 。 


dependencies: 
- name: rabbitmq 
version: 1.2.3 
repository: http://example.com/charts 


name: memcached 
version: 3.2.1 
repository: http://another.example.com/charts 
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在 安装 过 程 中 ， 依 赖 的 chart 也 会 被 一 起 安装 。 





(5) values.yaml 


chart xx FF 4E BAY TR eS BET XE ILA, fü values.yamlJll fe f 
了 这 些 配 置 参 数 的 默认 值 ， 如 图 11-24 所 示 。 





## mysql image version 
image: "mysql" 
imageTag: "5.7.14" 


## Specify password for root user 

## 

## Default: random 10 character string 
# mysqlRootPassword: testing 


## Create a database user 
## 

# mysqlUser: 

# mysqlPassword: 


imagePullPolicy: IfNotPresent 


## Persist data to a persitent volume 
persistence: 
enabled: true 
## If defined, storageClassName: <storageClass> 
## If set to "-", storageClassName: "", which disables dynamic provisioning 
## 
# storageClass: "-" 
accessMode: ReadWriteOnce 
size: 8Gi 


## Configure resource requests and limits 
Hit 


resources: 
requests: 
memory: 256Mi 
cpu: 100m 


# Custom mysql configuration files used to override default mysql settings 
configurationFiles: 

# mysql.cnf: |- 

# [mysqld] 

# skip-name-resolve 





图 11-24 


(6) templates 目 录 


各 类 Kubernetes 资 源 的 配置 模板 都 放置 在 这 里 。Helm 会 将 
values.yaml 中 的 参数 值 注入 模板 中 ， 生 成 标准 的 YAML 配 置 文件 。 


模板 是 chart 最 重要 的 部 分 ， 也 是 Helm 最 强大 的 地 方 。 模 板 增加 了 
应 用 部 署 的 灵活 性 ， 能 够 适用 不 同 的 环境 ， 我 们 后 面 会 详细 讨论 。 


(7) templates/NOTES.txt 


chart 的 简易 使 用 文档 ，chart 安 装 成 功 后 会 显示 此 文档 内 容 ， 如 图 
11-25 所 示 。 


MySQL can be accessed via port 3306 on the following DNS name from within your cluster: 
{{ template "mysql.fullname" . }}.{{ .Release.Namespace }}.svc.cluster.local 


To get your root password run: 

kubectl get secret --namespace {{ .Release.Namespace }} {{ template "mysql.fullname" . 1] 
To connect to your database: 
1. Run an Ubuntu pod that you can use as a client: 

kubectl run -i --tty ubuntu --image-ubuntu:16.04 --restart-Never -- bash -il 


2. Install the mysql client: 


$ apt-get update && apt-get install mysql-client -y 


3. Connect using the mysql cli, then provide your password: 
$ mysql -h {{ template "mysql.fullname" . }} -p 
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与 模板 一样， 可 以 在 NOTE HARE SM, nemis 





11.5.2 chart 


Helm 通 过 模板 创建 Kubernetes 能 够 理解 的 YAML 格 式 的 资源 配置 文 
件 ， 我 们 将 通过 例子 来 学 习 如 何 使 用 模板 。 


以 templates/secrets.yaml 为 例 ， 如 图 11-26 所 示 。 


apiVersion: v1 
kind: Secret 


: {{ template 


: {{ template 


release: 
heritage: 
type: Opaque 
data: 
{{ if .Values.mysqlRootPassword }} 
mysql-root-password: {{ .Values. oe | b64enc | quote }} 
{{ else }} 
aq. root-password: {{ randAlphaNum | b64enc | quote }} 
ii end }} 
{{ if .Values.mysqlPassword }} 
mysql-password: {{ .Values. re or | b64enc | quote }} 
{{ else }} 
mysql- ES 11 randAlphaNum | b64enc | quote }} 
{{ end 11 
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从 结构 上 看 ， 文 件 的 内 容 非常 像 Secret 配 置 ， 只 是 大 部 分 属性 值 变 
成 了 {{ xxx }}。 这 些 {{ xxx 小 实际 上 是 模板 的 语法 。Helm 采 用 了 Go 语 
言 的 模板 来 编写 chart。Go 模 板 非常 强大 ， 文 持 变 量 、 对 象 、 函 数 、 流 
控制 等 功能 。 下 面 我 们 通过 解析 templates/secrets.yaml 快 速 学 习 模 板 。 


© {{ template "mysql.fullname" . }} 定 义 Secret 的 name。 关 键 字 
template 的 作用 是 引用 一 个 子 模板 mysqlfullname。 这 个 子 模板 是 在 
templates/_helpers.tp] 文 件 中 定义 的 ， 如 网 11-27 所 示 。 














[(/* vim: set filetype-mustache: */}} 

LZ 

Expand the name of the chart. 

{{- define "mysql.name" -}} 

{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" -}} 
{{- end -}} 


{{/* 

Create a default fully qualified app name. 

We truncate at 63 chars because some Kubernetes name fields are limited to this 
1 


{{- define "mysql.fullname" -}} 

{{- $name := default .Chart.Name .Values.nameOverride -}} 

{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" -}} 
{{- end -}} 





图 11-27 


这 个 定义 还 是 很 复杂 的 ， 因 为 它 用 到 了 模板 语言 中 的 对 象 、 函 数 、 
流 控制 等 概念 。 现 在 看 不 全 没关系 ， 这 里 我 们 学 习 的 重点 是 : 如 果 存 在 


一 些 信息 多 个 模板 都 会 用 到 ， 则 可 在 templates/_helpers.tpl] 中 将 其 定义 为 
子 模 板 ， 然 后 通过 templates 函 数 引 用 。 


这 里 mysql.fullname 是 由 release 与 chart 二 者 名 字 拼 接 组 成 的 。 
根据 chart 的 最 佳 实 践 ， 所 有 资源 的 名 称 都 应 该 保持 一 致 。 对 于 我 们 
这 个 chart， 无 论 Secret 还 是 Deployment、PersistentVolumeClaim、 


Service， 它 们 的 名 字 都 是 子 模板 mysqlfullname 的 值 。 


@ Chart 和 和 Release 是 Helm 预 定义 的 对 象 ， 每 个 对 象 都 有 上 自己 的 属 
性 ， 可 以 在 模板 中 使 用 。 如 果 使 用 下 面 的 命令 安装 chart: 


helm install stable/mysql -n my 


那么 : 








{{ .Chart.Name }} 的 值 为 mysql。 

{{ .Chart. Version }} 的 值 为 0.3.0。 

{{ .Release.Name }} 的 值 为 my。 

{{ .Release.Service }} 始 终 取 值 为 Tiller。 

{{ template "mysql.fullname" . }} 计 算 结 果 为 my-mysgql。 


(3) 这 里 指定 mysql-root-password 的 值 ， 不 过 使 用 了 if-else 的 流 控 
制 ， 其 逻辑 为 :如果 .Values.mysqlRootPassword 有 值 ， 就 对 其 进行 
base64 编 码 ， 盏 则 随机 生成 一 个 10 位 的 字符 串 并 编码 。 


Values 也 是 预定 义 的 对 象 ， 代 表 的 是 values.yaml 文 
件 。.Values.mysqlRootPassword 则 是 values.yaml 中 定义 的 
mysqlRootPassword 参 数 ， 如 图 11-28 所 示 。 


## mysql image version 
HH 

image: "mysql" 
imageTag: "5.7.14" 


## Specify password for root user 
## 


## Default: random 10 character string 
# mysqlRootPassword: testing 


## Create a database user 
HH 

# mysqlUser: 

# mysqlPassword: 





图 11-28 


为 mysqlRootPassword 被 注释 挥 了 ， 没 有 赋值 ， 所 以 逻辑 判断 会 
走 else， 即 随机 生成 密码 。 


randAlphaNum、b64enc、quote 都 是 Go 模板 语言 文 持 的 函数 ， 函 数 
之 间 可 以 通过 管道 连接。{{t randAlphaNum 10 | b64enc | quote }} 的 作用 
是 首先 随机 产生 一 个 长 度 为 10 的 字符 串 ， 然 后 将 其 base64 编 码 ， 最 后 两 
边 加 上 双 引 号 。 


templates/secrets.yaml 这 个 例子 展示 了 chart 模 板 主要 的 功能 ， 我 们 最 
大 的 收获 应 该 是 : 模板 将 chart 参 数 化 了 ， 通 过 values.yaml 可 以 灵活 定制 
应 用 。 


无 论 多 复杂 的 应 用 ， 用 户 都 可 以 用 Go 模板 语言 编写 出 chart。 无 非 
是 使 用 到 更 多 的 函数 、 对 象 和 流 控 制 。 对 于 初学 者 ， 建 议 尽量 参考 官方 
的 chart。 根 据 二 八 定律 ， 这 些 chart 已 经 覆盖 了 绝 大 部 分 情况 ， 而 且 采 用 
了 最 佳 实践 。 如 何 遇 到 不 懂 的 函数 、 对 象 和 其 他 语法 ， 可 参考 官网 文档 
https://docs.helm.sh. 








11.5.3 ”再 次 实践 MySQL chart 


学 习 了 chart 结 构 和 模板 的 知识 后 ， 现 在 重新 实践 一 次 MySQL 
chart， 相 信 会 有 更 多 收获 。 


1. chart 安 装 前 的 准备 


作为 准备 工作 ， 安 装 之 前 需要 先 清 楚 chart 的 使 用 方法 。 这 些 信 息 通 
常 记录 在 values.yaml 和 README.md 中 。 除 了 下 载 源 文件 查看 ， 执 行 
helm inspect values 可 能 是 更 方便 的 方法 ， 如 图 11-29 所 示 。 





ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ helm inspect values stable/mysql 
## mysql image version 

## ref: https://hub.docker.com/r/library/mysql/tags/ 
D 2 

image: "mysql" 

imageTag: "5.7.14" 


## Specify password for root user 
## 
## Default: random 10 character string 


# mysqlRootPassword: testing 


## Create a database user 
## 

# mysqlUser: 

# mysqlPassword: 


## Allow unauthenticated access, uncomment to enable 
## 
# mysqlAllowEmptyPassword: true 
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输出 的 实际 上 是 values.yaml 的 内 容 。 阅 读 注 释 就 可 以 知道 MySQL 
chart 文 持 哪 些 参数 ， 安 装 之 前 需要 做 哪些 准备 。 其 中 有 一 部 分 是 关于 存 
储 的 ， 如 图 11-30 所 示 。 


persistence: 
enabled: true 
## database data Persistent Volume Storage Class 
## If defined, storageClassName: <storageClass> 
## If set to "-", storageClassName: "", which disables dynamic provisioning 
## If undefined (the default) or set to null, no storageClassName spec is 
## = set, choosing the default provisioner. (gp2 on AWS, standard on 
GKE, AWS & OpenStack) 


# storageClass: "-" 
accessMode: ReadWriteOnce 
size: 8Gi 





[11-30 


chart 定 义 了 一 个 PersistentVolumeClaim， 申 请 8GB 的 
PersistentVolume。 由 于 我 们 的 实验 环境 不 支持 动态 供给 ， 因 此 要 预先 创 
建 好 相应 的 PV， 其 配置 文件 mysql-pv.yml 的 内 容 如 图 11-31 所 示 。 


apiVersion: v1 
kind: PersistentVolume 
metadata: 
name: mysql-pv 
spec: 
accessModes: 
- ReadWriteOnce 


capacity: 
storage: 8Gi 
persistentVolumeReclaimPolicy: Retain 


nfs: 
path: /nfsdata/mysql-pv 
server: 192.168.56.105 





图 11-31 


创建 PY mysql-pv， 如 图 11-32 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f mysql-pv.yml 
persistentvolume "mysql-pv" created 

ubuntuék8s -master : ~$ 


ubuntu@k8s-master:~$ kubectl get pv 

NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS 
mysql-pv 8Gi RWO Retain Available 

ubuntu@k8s-master : ~$ 





图 11-32 
接 下 来 束 可 以 安装 chart 了 了 。 
2. 定制 化 安装 chart 
除了 接受 values.yaml 的 默认 值 ， 我 们 还 可 以 定制 化 chart， 比 如 设置 


mysqlRootPassword. 
Helm 有 两 种 方式 传递 配置 参数 : 
(1) 指定 自己 的 values 文 件 。 通 第 的 做 法 是 首先 通过 helm ^ inspect 


values mysql >myvalues.yaml 生 成 values 文 件 ， 然 后 设置 
mysqlRootPassword， 最 后 执行 helm install--values=myvalues.yaml 
mysql. 


(2) 通过 --set 直 接 传 入 参数 值 ， 如 图 11-33 所 示 。 


ubuntuek8s master: ~$ 

ubuntuék8s-master:-$ helm install stable/mysql --set mysqlRootPassword-abc123 -n my 
NAME : my 

LAST DEPLOYED: Thu Oct 19 14:24:56 2017 

NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 

==> vi1/Service 

NAME CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
my-mysql 10.104.59.139 <none> 3306/TCP Qs 


==> vibetal/Deployment 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
my-mysql 1 T 1 0 0s 


==> vi/Secret 
NAME TYPE DATA AGE 
my-mysql Opaque 2 Qs 


==> vi/PersistentVoLumeCLaim 
NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE 
my-mysql Pending Qs 





图 11-33 


mysqlRootPassword 设 置 为 abc123。 另 外 ，-n 设 置 release 为 my， 各 类 
资源 的 名 称 即 为 my-mysql。 


通过 helm list 和 helm status 可 以 查看 chart 的 最 新 状态 ， 如 图 11-34 所 
Te 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ helm list 

NAME REVISION UPDATED STATUS CHART NAMESPAC 
my 1 Thu Oct 19 14:24:56 2017 DEPLOYED mysql-0.3.0 default 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ helm status my 

LAST DEPLOYED: Thu Oct 19 14:24:56 2017 

NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 
==> vi/Secret 
NAME TYPE DATA AGE 


my-mysql Opaque 2 8m 


==> v1/PersistentVoLumeCLaim 
NAME S| VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE 
my-mysql mysql-pv 8Gi RWO 8m 


==> v1/Service 
NAME CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
my-mysql 10.104.59.139 <none> 3306/TCP 8m 


==> vlbeta1/Deployment 
NAME DESIRED CURRENT UP-TO-DATE 
my-mysql 1 1 T 





图 11-34 


PVC 已 经 Bound，Deployment 也 变 为 AVAILABLE。 


11.5.4 FÆ M lZ release 


release 发 布 后 可 以 执行 helm upgrade 对 其 进行 升级 ， 通 过 --values 或 -- 
set 应 用 新 的 配置 。 比 如 将 当前 的 MySQL 版 本 升级 到 5.7.15， 如 图 11-35 
所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ helm upgrade --set imageTag=5.7.15 my stable/mysq 
Release "my" has been upgraded. Happy Helming! 

LAST DEPLOYED: Thu Oct 19 14:37:46 2017 

NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 

==> vl/Secret 

NAME TYPE DATA AGE 
my-mysql Opaque 2 12m 


==> v1/PersistentVolumeClaim 
NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE 
my-mysql Bound  mysql-pv 8Gi RWO 12m 


==> vil/Service 
NAME CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
my-mysql 10.104.59.139 <none> 3306/TCP 12m 


==> vibetal/Deployment 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
my-mysql 1 1 1 0 12m 
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等 待 一 些 时 间 ， 升 级 成 功 ， 如 图 11-36 所 示 。 





UDU UCKSS—Mma er. ~p 
ubuntuék8s-master:-$ kubectl get deployment my-mysql -o wide 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINER(S) 
my-mysql 1 1 1 4i 5m my-mysql 
ubuntu@k8s-master : ~$ 





图 11-36 


helm history 可 以 查看 release 所 有 的 版 本 。 通 过 helm rollback 可 以 回 
深 到 任何 版 本 ， 如 图 11-37 所 示 。 


ubuntu@k8s-master:~$ helm history my 

REVISION UPDATED STATUS CHART 

1 Thu Oct 19 11:18:55 2017 SUPERSEDED mysql-0.3.0 

2 Thu Oct 19 11:20:01 2017 DEPLOYED mysql-0.3.0 Upgrade 


ubuntu@k8s-master :~ 
ubuntu@k8s-master:~$ helm rollback my 1 
Rollback was a success! Happy Helming! 
ubuntuek8s-master : ~$ 





图 11-37 


回 深 成 功 ，MySQL 恢 复 到 5.7.14， 如 图 11-38 所 示 。 


ubuntu@k8s-master:~$ helm history my 
REVISION UPDATED STATUS DESCRIPTION 
Thu Oct 19 11:18:55 2017 SUPERSEDED -0.3. Install complete 


Thu Oct 19 11:20:01 2017 SUPERSEDED -0.3. Upgrade complete 
Thu Oct 19 11:27:01 2017 DEPLOYED -0.3. Rollback to 1 
ubuntuék8s-master: ~$ 


ubuntuék8s-master:-$ kubectl get deployment my-mysql -o wide 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERCS) | IMAGE(S) SE 
my-mysql 1 1 ds 1 8m my-mysql mysql:5.7.14] ap 


ubuntu@k8s-master : ~$ 
图 11-38 


11.5.5 ”开发 目 己 的 chart 





Kubernetes 给 我 们 提供 了 大 量 官方 chart， 不 过 要 部 署 微服 务 应 用 ， 
是 需要 开发 自己 的 chart， 下 面 就 来 实践 这 个 主题 。 


1. 创 建 chart 





执行 helm create mychart 命 令 ， 创 建 chart mychart， 如 图 11-39 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ helm create mychart 
Creating mychart 
ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ tree mychart 
mychart 
| charts 
|- 一 Chart.yaml 
H—— templates 

F— deployment.yaml 


H—— ingress.yaml 
lI-— NOTES.txt 
| L— service. yamlL 
L— values.yaml 


| 
| I-— _helpers.tpl 
| 
| 


2 directories, 7 files 
ubuntu@k8s-master: ~$ 
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Helm 会 帮 我 们 创建 目录 mychart， 并 生成 各 类 chart 文 件 。 这 样 我 们 
就 可 以 在 此 基础 上 开发 自己 的 chart 了 。 





新 建 的 chart 默 认 包含 一 个 nginx 应 用 示例 ，values.yaml 内 容 如 图 11- 
40 所 示 。 


# Default values for mychart. 
# This is a YAML-formatted file. 
# Declare variables to be passed into your templates. 
replicaCount 1 
image: 
repository: nginx 
tag: stable 
pullPolicy: IfNotPresent 
service: 


name: nginx 

type: ClusterIP 

externalPort: 80 

internalPort: 80 
ingress: 

enabled: false 


d 


# Used to create an Ingress record. 
hosts: 
- chart-example.local 

图 11-40 


开发 时 建议 大 家 参考 官方 chart 中 的 模板 values.yaml、Chart.yaml， 
里 面包 含 了 大 量 最 佳 实践 和 最 常用 的 函数 、 流 控制 ， 这 里 束 不 一 一 展开 
Ke 

2. 调试 chart 


只 要 是 程序 就 会 有 bug，chart 也 不 例外 。Helm 提 供 了 debug 的 工具 : 
helm lint 和 helm install --dry-run --debug. 


helm lint 会 检测 chart 的 语法 ， 报 告 错 误 以 及 给 出 建议 。 


比如 我 们 故意 在 values.yaml 的 第 8 行 漏 掉 了 行 尾 的 那个 冒号 ， 如 图 
11-41 所 示 。 











# Decl Variables to be pas r templates. 
replicaCount: 1 
image: 

repository: nginx 


tag: stable 
s Ceuiipoticy Tetpresa 
9 service: 
10 name: nginx 
11 type: ClusterIP 
12 externalPort: 80 
13 internalPort: 80 





图 11-41 


helm lint mychart 会 指出 这 个 语法 错误 ， 如 图 11-42 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ helm lint mychart 
==> Linting mychart 
[INFO] Chart.yaml: icon is recommended 
[ERROR] values.yaml: unable to parse YAML 
error converting YAML to JSON: yaml: line 8: could not find expected ':' 


Error: 1 chart(s) linted, 1 chart(s) failed 
ubuntu@k8s-master : ~$ 





图 11-42 


mychart 目 录 被 作为 参数 传递 给 helm ”lint。 错 误 修复 后 则 能 通过 检 
测 ， 如 图 11-43 所 示 。 





ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ helm lint mychart 
==> Linting mychart 
[INFO] Chart.yaml: icon is recommended 


1 chart(s) linted, no failures 
ubuntu@k8s-master : ~$ 
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helm install --dry-run --debug 会 模拟 安装 chart， 并 输出 每 个 模板 生成 
的 YAMEL 内 容 ， 如 图 11-44、 图 11-45 所 示 。 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ helm install --dry-run mychart --debug 
[debug] Created tunnel using local port: '46295' 


[debug] SERVER: "localhost:46295" 


[debug] Original chart version: "" 
[debug] CHART PATH: /home/ubuntu/mychart 


NAME : solitary-kudu 

REVISION: 1 

RELEASED: Fri Oct 20 09:59:51 2017 
CHART: mychart-0.1.0 

USER-SUPPLIED VALUES: 

{} 


COMPUTED VALUES: 
image: 
pullPolicy: IfNotPresent 
repository: nginx 
tag: stable 
ingress: 
annotations: null 
enabled: false 
hosts: 
- chart-example. local 
tls: null 
repLicaCount: 1 
resources: {} 
service: 
externalPort: 80 
internalPort: 8@ 
name: nginx 
type: ClusterIP 


HOOKS: 
MANIFEST: 





图 11-44 


# Source: mychart/templates/service.yaml 
apiVersion: v1 
kind: Service 
metadata: 
name: solitary-kudu-mychart 
labels: 
app: mychart 
chart: mychart-0.1.0 
release: solitary-kudu 
heritage: Tiller 
spec: 
type: ClusterIP 
ports: 
- port: 80 
targetPort: 80 
protocol: TCP 
name: nginx 
selector: 
app: mychart 
release: solitary-kudu 
# Source: mychart/templates/deployment.yaml 
apiVersion: extensions/vibetal 
kind: Deployment 
metadata: 
name: solitary-kudu-mychart 
labels: 


app: mychart 

chart: mychart-0.1.0 
release: solitary-kudu 
heritage: Tiller 


spec: 
replicas: 1 
template: 
metadata: 
labels: 
app: mychart 
release: solitary-kudu 
spec: 
containers: 
- name: mychart 
image: "nginx:stable" 
imagePullPolicy: IfNotPresent 
ports: 
- containerPort: 80 
LivenessProbe: 
httpGet: 
path: / 
port: 80 
readinessProbe: 
httpGet: 
path: / 
port: 80 
resources: 
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我 们 可 以 检测 这 些 输出 ， 判 断 是 否 与 预期 相符 。 
同样 ，mychart 目 录 作 为 参数 传递 给 helm install --dry-run --debug。 
3. 安装 chart 
当 我 们 准备 就 绕 ， 就 可 以 安装 chart 了 。Helm 支 持 四 种 安装 方法 : 
(1) 安装 仓库 中 的 chart， 例 如 helm install stable/nginx。 
(2) 通过 tar 包 安装 ， 例 如 helm install ./nginx-1.2.3.tgz。 
(3) 通过 chart 本 地 目录 安装 ， 例 如 helm install .nginx。 


(4) 通过 URL 安 装 ， 例 如 helm install 


https://example.com/charts/nginx-1.2.3.tgz. 


Te 


这 里 我 们 使 用 本 地 目录 安装 ， 如 图 11-46 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ helm install mychart 
NAME: opinionated-nightingale 

LAST DEPLOYED: Fri Oct 20 10:14:06 2017 
NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 

==> vl/Service 

NAME CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
opinionated-nightingale-mychart 10.100.28.221 <none> 80/TCP Qs 


==> vibetai/DepLoyment 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
opinionated-nightingale-mychart 1 1 1 0 Qs 


NOTES: 

1. Get the application URL by running these commands: 
export POD.NAME-$(kubectl get pods --namespace default -l "appemychart,release-opi 
echo "Visit http://127.0.0.1:8080 to use your application" 
kubectl port-forward $POD. NAME 8080:80 





ubuntu@k8s-master : ~$ 


图 11-46 


当 chart 部 署 到 Kubernetes 集 群 后 ， 便 可 以 对 其 进行 更 为 全 面 的 测试 


4. 将 charti 答 加 到 仓库 


chart 通 过 测试 后 可 以 添加 到 仓库 中 ， 团 队 其 他 成 员 就 能 够 使 用 了 。 
任何 HTTP Server 都 可 以 用 作 chart 仓 库 。 下 面 演示 在 k8s-nodel 
192.168.56.106 上 搭建 仓库 。 





(1) 在 k8s-nodel 上 启动 一 个 httpd 容 器 ， 如 图 11-47 所 示 。 


root@k8s-node1: ~# 
root@k8s-node1:~# mkdir /var/www 
root@k8s-node1: ~# 


root@k8s-node1:~# docker run -d -p 8080:80 -v /var/www/:/usr/local/apache2/htdocs/ httpd 
f3d5f0779a04a3074bd332764263e0283d8548e8f9b2b96dc744e098b45ce075 
root@k8s-node1:~# 





图 11-47 


(2) 通过 helm package 将 mychart 打 包 ， 如 图 11-48 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ helm package mychart 

Successfully packaged chart and saved it to: /home/ubuntu/mychart-0.1.0.tgz 
ubuntu@k8s-master:~$ 





图 11-48 


(3) 执行 helm repo index 生 成 仓库 的 index 文 件 ， 如 图 11-49 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ mkdir myrepo 

ubuntu@k8s-master:~$ mv mychart-0.1.0.tgz myrepo/ 

ubuntu@k8s-master:~$ helm repo index myrepo/ --url http://192.168.56.106:8080/charts 
ubuntu@k8s-master:~$ ls myrepo/ 

index.yaml  mychart-0.1.0.tgz 

ubuntuék8s-master : ~$ 
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Helm 会 扫描 myrepo 目 录 中 的 所 有 tgz 包 并 生成 index.yaml。--url 指 定 
的 是 新 仓库 的 访问 路 径 。 新 生成 的 index.yaml 记 录 了 当前 仓库 中 所 有 
chart 的 信息 ， 如 图 11-50 所 示 。 


apiVersion: v1 
entries: 
mychart: 
- apiVersion: v1 
created: 2017-10-21T16:39:39.184818935408:00 
description: A Helm chart for Kubernetes 


digest: ae8d71380024d4320144dc8638ec37202823e9207445caf08a660d154b26e936ea 
name: mychart 
urls: 
- http://192.168.56.106:8080/charts/mychart-0.1.0.tgz 
version: 0.1.0 
generated: 2017-10-21T16:39:39.184265707+08 : 00 
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当前 只 有 mychart 这 一 个 chart。 


(4) 将 mychart-0.1.0.tgz 和 index.yaml 上 传 到 k8s-nodel 
的 /Var/www/charts 目 录 ， 如 图 11-51 所 示 。 


root@k8s-node1:~# 
rootGk8s-node1:-£ ls /var/www/charts/ 


index.yaml  mychart-0.1.0.tgz 
root@k8&s-node1:~# 
图 11-51 


(5) 通过 helm repo add 将 新 仓库 添加 到 Helm， 如 图 11-52 上 所 示 。 


ubuntu@k8s-master: ~$ 

ubuntu@k8s-master:~$ helm repo add newrepo http://192.168.56.106:8080/charts 
"newrepo" has been added to your repositories 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ helm repo list 

NAME URL 

stable https://kubernetes-charts.storage.googleapis.com 

local  http://127.0.0.1:8879/charts 


newrepo http://192.168.56.106:8080/charts 
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仓库 命名 为 newrepo，Helm 会 从 仓库 下 载 index.yaml。 


(6) 现在 已 经 可 以 repo search 到 mychart 了 ， 如 图 11-53 所 示 。 


ubuntuek8s-master : ~$ 
ubuntu@k8s-master:~$ helm search mychart 
NAME VERSION DESCRIPTION 


local/mychart @.1.@ A Helm chart for Kubernetes 
newrepo/mychart 0.1.0 A Helm chart for Kubernetes 
ubuntu@k8s-master : ~$ 





图 11-53 


除了 newrepo/mychart， 这 里 还 有 一 个 local/mychart。 这 是 因为 在 执 
行 第 2 步 打 包 操 作 的 同时 ，mychart 也 被 同步 到 了 local 的 仓库 。 


(7) 已 经 可 以 直接 从 新 仓库 安装 mychart 了 ， 如 图 11-54 所 示 。 





ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ helm install newrepo/mychart 
NAME: guilded-jellyfish 

LAST DEPLOYED: Sat Oct 21 16:49:31 2017 
NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 

==> vi/Service 

NAME CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
guilded-jellyfish-mychart 10.109.@.87 <none> 80/TCP Qs 


==> vibetal/DepLoyment 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
guilded-jellyfish-mychart 1 1 1 0 0s 


NOTES: 

1. Get the application URL by running these commands: 
export POD NAME-$(kubectl get pods --namespace default -1 "app-mychart,r 
echo "Visit http://127.0.0.1:8080 to use your application" 
kubectl port-forward $POD_NAME 8080:80 
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(8) 若 以 后 仓库 添加 了 新 的 chart， 则 需要 用 helm repo update 更 新 
本 地 的 index， 如 图 11-55 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ helm repo update 

Hang tight while we grab the latest from your chart repositories... 
...Skip local chart repository 





...Successfully got an update from the "newrepo" chart repository 
...Successfully got an update from the "stable" chart repository 
Update Complete. Happy Helming! $ 

ubuntu@k8s-master : ~$ 





图 11-55 


这 个 操作 相当 于 Ubutun 的 apt-get update. 


11.6 ”小结 


本 章 我 们 学 习 了 Kubernetes 包 管理 器 Helm。 


Helm 让 我 们 能 够 像 apt 管 理 deb 包 那样 安装 、 部 普 、 升 级 和 删除 容 需 
化 应 用 


Helm 由 客户 端 和 Tiller 服 务 器 组 成 。 客 户 端 负 责 管理 chart， 服 务 器 


负责 管理 release。 


chart 是 Helm 的 应 用 打包 格式 ， 它 由 一 组 文件 和 目录 构成 。 其 中 最 
重要 的 是 模板 ， 模 板 中 定义 了 Kubernetes 各 类 资源 的 配置 信息 ，Helm 在 
部 署 时 通过 values.yaml 实 例 化 模板 。 


Helm 人 允许 用 户 开 发 自己 的 chart， 并 为 用 户 提 供 了 调试 工具 。 用 户 
可 以 搭建 自己 的 chart 仓 库 ， 在 团队 中 共享 chart。 


Helm 帮 助 用 户 在 Kubernetes 上 高 效 地 运行 和 管理 微服 务 架 构 应 用 ， 
Helm 非 常 重要。 








第 12 章 ”网 络 


本 章 我 们 讨论 Kubernetes 网 络 这 个 重要 主题 。 


Kubernetes 作 为 编排 引擎 管理 着 分 布 在 不 同 节 ut. 
Pod、Service、 外 部 组 件 之 间 需 要 一 种 可 靠 的 方式 找到 彼此 并 进行 
信 ，Kubernetes 网 络 则 负责 提供 这 个 保障 。 本 章 包 括 如 下 内 容 : 


(1) Kubernetes 网 络 模型 。 
(2) 各 种 网 络 方案 。 


(3) Network Policy。 
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Pod 都 有 自己 的 IP 地 址 ，Pod 之 间 不 需要 配置 NAT 束 能 直接 通信 。 男 外 ， 
同一 个 Pod 中 的 容器 共享 Pod 的 IP， 能 够 通过 localhost 通 信 。 


这 种 网 络 模型 对 应 用 开发 者 和 管理 员 相 当 友 好 ， 应 用 可 以 非常 方便 
地 从 传统 网 络 迁移 到 Kubernetes。 每 个 Pod 可 被 看 作 是 一 个 个 独立 的 系 
统 ， 而 Pod 中 的 容器 则 可 被 看 作 同 一 系统 中 的 不 同 进程 。 


下 面 讨论 在 这 个 网 络 模型 下 集群 中 的 各 种 实体 如 何 通 信 。 知 识 点 前 
面 都 已 经 涉及 ， 这 里 可 当 作 复 习 和 总 结 。 


1. Pod 内 容器 之 间 的 通信 


当 Pod 被 调度 到 某 个 节点 ，Pod 中 的 所 有 容器 都 在 这 个 节点 上 运行 ， 
这 些 容器 共 k 享 相同 的 本 地 文件 系统 、 IPC 和 网 络 命名 空间 。 


不 同 Pod 之 间 不 存在 端口 冲突 的 问题 ， 因 为 每 个 Pod 都 有 自己 的 IP 地 
址 。 当 某 个 容器 使 用 localhost 时 ， 意 味 着 使 用 的 是 容器 所 属 Pod 的 地 址 空 
间 。 




















比如 Pod A 有 两 个 容器 container-Al1 和 container-A2，container-A1l 在 
端口 1234 上 监听 ， 当 container-A2 连 接 到 localhost:1234 时 ， 实 际 上 就 是 在 
访问 container-A1。 这 不 会 与 同一 个 市 点 上 的 Pod B 冲 突 ， 即使 Pod B 中 
的 容器 container-B1 也 在 监听 1234 端 口 。 





2. Pod 之 间 的 通信 


Pod 的 IP 是 集群 可 见 的 ， 即 集群 中 的 任何 其 他 Pod 和 节点 都 可 以 通过 
IP 直 接 与 Pod 通 信 ， 这 种 通信 不 需要 借助 任何 网 络 地 址 转换 、 隧 道 或 代 
理 技术 。Pod 内 部 和 外 部 使 用 的 是 同一 个 IP， 这 也 意味 着 标准 的 命名 服 
务 和 发 现 机 制 ， 比 如 DNS 可 以 直接 使 用 。 


3. Pod 与 Service 的 通信 





Pod 间 可 以 直接 通过 IP 地 址 通信 ， 但 前 提 是 Pod 知 道 对 方 的 卫 。 在 
Kubernetes 集 群 中 ，Pod 可 能 会 频繁 地 销毁 和 创建 ， 也 就 是 说 Pod 的 IP 不 
是 固定 的 。 为 了 解决 这 个 问题 ，Service 提 供 了 访问 Pod 的 抽象 层 。 无 论 
后 端的 Pod 如 何 变 化 ，Service 都 作为 稳定 的 前 端 对 外 提供 服务 。 同 时 ， 
Service 还 提供 了 高 可 用 和 负载 均衡 功能 ，Service 负 责 将 请 求 转发 给 正确 
的 Pod。 


4. 外 部 访问 

无 论 是 Pod 的 IP 还 是 Service 的 Cluster IP， 它 们 只 能 在 Kubernetes 和 集群 
中 可 见 ， 对 集群 之 外 的 世界 ， 这 些 IP 都 是 私有 的 。 

Kubernetes 提 供 了 两 种 方式 让 外 界 能 够 与 Pod 通 信 : 


e NodePort。Service 通 过 Cluster 节 点 的 静态 端口 对 外 提供 服务 。 外 部 
可 以 通过 <NodeIP>:<NodePort> 访 问 Service。 

e LoadBalancer。Service 利 用 cloud provider 提 供 的 load balancer 对 外 提 
供 服 务 ，cloud provider 负 责 将 load balancer 的 流量 导 疝 Service。 H 
前 支持 的 cloud providerx 有 GCP、AWS、Azur 等 。 


12.2. 各 种 网 络 方案 


网 络 模型 有 了 ， 如 何 实现 呢 ? 
为 了 保证 网 络 方案 的 标准 化 、 扩 展 性 和 灵活 性 ，Kubernetes 采 用 了 


Container Networking Interface (CNI) 规范 。 


CNI 是 由 CoreOS 提 出 的 容器 网 络 规范 ， 使 用 了 插件 (Plugin) 模型 
创建 容 右 的 网 络 栈 ， 如 图 12-1 所 示 。 


Container Network Interface (CNI) Drivers 


Container 
Runtime 


Container Network Interface (CNI) 





Loopback Bridge PTP MACvlan IPvlan 3rd-Party 
Plugin Plugin Plugin Plugin Plugin Plugin 


图 12-1 


CNI 的 优点 是 支持 多 种 容器 runtime， 不 仅仅 是 Docker。CNI 的 插件 
模型 支持 不 同 组 织 和 公司 开发 的 第 三 方 插件 ， 这 对 运 维 人 员 来 说 很 有 了 吸 
引力 ， 可 以 灵活 选择 适合 的 网 络 方案 。 


目前 已 有 多 种 支持 Kubernetes 的 网 络 方案 ， 比 如 Flannel、Calico、 
Canal. Weave _ Net 等 。 因 为 它们 都 实现 了 CNI 规 范 ， 用 户 无 论 选 择 哪 种 
方案 ， 得 到 的 网 络 模型 都 一 样 ， 即 每 个 Pod 都 有 独立 的 IP， 可 以 直接 通 
信 。 区 别 在 于 不 同方 案 的 底层 实现 不 同 ， 有 的 采用 基于 VxLAN 的 
Overlay 实 现 ， 有 的 则 是 Underlay， 性 能 上 有 区 别 。 再 有 就 是 是 否 文 持 
Network Policy. 














12.3 Network Policy 


Network Policy 是 Kubemetes 的 一 种 资源 。Network Policy 通 过 Label 
选择 Pod， 并 指定 其 他 Pod 或 外 界 如 何 与 这 些 Pod 通 信 。 


默认 情况 下 ， 所 有 Pod 是 非 隔 离 的 ， 即 任何 来 源 的 网 络 流量 都 能 够 
访问 Pod， 没 有 任何 限制 。 当 为 Pod 定 义 了 Network Policy 时 ， 只 有 Policy 
允许 的 流量 才能 访问 Pod。 


不 过 ， 不 是 所 有 的 Kubernetes 网 络 方案 都 支持 Network Policy。 比 如 
Flannel 就 不 文 持 ，Calico 是 文 持 的 。 我 们 接 下 来 将 用 Canal 来 演示 
Network Policy. Canal 这 个 开源 项 目 很 有 意思 ， 它 用 Flannel 实 现 
Kubernetes 集 群 网 络 ， 同 时 又 用 Calico 实 现 Network Policy. 





12.3.1 5 Canal 


部 署 Canal 与 部 署 其 他 Kubernetes 网 络 方案 非常 类 似 ， 都 是 在 执行 了 
kubeadm init 初始 化 Kubernetes 集 群 之 后 通过 kubectl apply 安 装 相应 的 网 
络 方案 。 也 就 是 说 ， 没 有 太 好 的 办 法 直接 切换 使 用 不 同 的 网 络 方案 ， 基 
本 上 只 能 重新 创建 集群 。 


要 销毁 当前 集群 ， 最 简单 的 方法 是 在 每 个 节点 上 执行 kubeadm 
reset， 然 后 就 可 以 按照 3.3.1 小 节 “ 初 始 化 Master” 中 的 方法 初始 化 集群 
Ja 





kubeadm init --apiserver-advertise-address 192.168.56.105 
--pod-network-cidr=10.244.0.0/16 


然后 按照 文档 https://kubernetes.io/docs/setup/independent/create- 
cluster-kubeadm/ 安 装 Canal。 文 档 列 出 了 各 种 网 络 方案 的 安装 方法 ， 如 
图 12-2 所 示 。 


Choose one... Calico Flannel Kube-router Romana Weave Net 


The official Canal set-up guide is here. 


Note: 


* For Canal to work correctly, --pod-network-cidr-10.244.0.0/16 has to be passed to kubeadm init. 


* Canal works on amd64 only. 


kubectl apply -f https://raw.githubusercontent.com/projectcalico/canal/master/k8s-install/1. 
kubectl apply -f https://raw.githubusercontent.com/projectcalico/canal/master/k8s-install/1. 


spat 


图 12-2 
执行 如 下 命令 部 署 Canal: 


kubectl apply -f 
https://raw.githubusercontent.com/projectcalico/canal/master/k8s- 
install/1.7/rbac.yaml 

kubectl apply -f 
https://raw.githubusercontent.com/projectcalico/canal/master/k8s- 
install/1.7/canal.yaml 


部 署 成 功 后 ， 可 以 查看 到 Canal 相 关 组 件 ， 如 图 12-3 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get --namespace-kube-system daemonset canal 

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE 
canal 3 3 3 3 3 <none> 5d 
ubuntu@k8s-master : ~$ 


ubuntu@k8s-master:~$ kubectl get --namespace=kube-system pod -o widelgrep canal 

canal-fkrl18 3/3 Running 0 5d 192.168.56.107 . k8s-node2 
canal-pqvq2 3/3 Running 0 5d 192.168.56.105 — k8s-maste 
canal-wtlhk 3/3 Running 0 5d 192.168.56.106 k8s-node1 
ubuntu@k8s-master :~$ 





图 12-3 


Canal 作 为 DaemonSet 部 署 到 每 个 节点 ， 属 于 kube-system 这 个 
namespace。 


12.3.2 Œ Network Policy 


为 了 演示 Network Policy， 我 们 先 部 署 一 个 httpd 应 用 ， 其 配置 文件 
httpd.yaml 如 图 12-4 所 示 。 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 
name: httpd 
spec: 
replicas: 
template: 
metadata: 
labels: 
run: httpd 


spec: 
containers: 
- name: httpd 
image: httpd:latest 
imagePullPolicy: IfNotPresent 
ports: 


- containerPort: 


apiVersion: v1 
kind: Service 
metadata: 

name: httpd-svc 

spec: 

type: NodePort 

selector: 
run: httpd 

ports: 

- protocol: TCP 
nodePort: 
port: 
targetPort: 





图 12-4 


httpd 有 三 个 副本 ， 通 过 NodePort 类 型 的 Service 对 外 提供 服务 。 部 署 
应 用 ， 如 图 12-5 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl apply -f httpd.yml 

deployment "httpd" created 

service "httpd-svc" created 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS IP NODE 


httpd-b5c6f48-gs7p2 1/1 Running 0 10.244.1.7  k8s-node1 
httpd-b5c6f48-p86tv 1/1 Running 0 10.244.1.8 — k8s-node1 
httpd-b5c6f48-qxzxg 1/1 Running 0 10.244.2.4 Kk8s-node2 
ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get service httpd-svc 

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 

httpd-svc NodePort 10.104.77.239 | «none» 8080:30000/TCP 2m 
ubuntu@k8s-master : ~$ 





图 12-5 


当前 没有 定义 任何 Network Policy， 验 证 应 用 可 以 被 访问 ， 如 图 12-6 
所 示 。 


(1) 启动 一 个 busybox Pod， 既 可 以 访问 Service， 也 可 以 Ping 到 副 
本 Pod。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl run busybox --rm -ti --image=busybox /bin/sh 
If you don't see a command prompt, try pressing enter. 

/ # 

/ € wget httpd-svc:8080 

Connecting to httpd-svc:8080 (10.104.77.239:8080) 

index.html 10096 | EE oe EK KK RR EH EK KK KKK 
/ # 

/ € ping 10.244.1.7 

PING 10.244.1.7 (10.244.1.7): 56 data bytes 

64 bytes from 10.244.1.7: seq-0 ttl-62 time-1.696 ms 

64 bytes from 10.244.1.7: seq-1 ttl-62 time-0.558 ms 

64 bytes from 10.244.1.7: seq-2 ttl-62 time-0.497 ms 


图 12-6 


(2) 集群 节点 既 可 以 访问 Service， 也 可 以 Ping 到 副本 Pod， 如 图 
12-7 所 示 。 





root@k8s-node2 :~# 

root@k8s-node2:~# curl 10.104.77.239:8080 
<html><body><h1>It works !</h1></body></html> 
root@k8s-node2:~# 

root@k8s-node2:~# ping -c 3 10.244.1.7 


PING 10.244.1.7 (190.244.1.7) 56(84) bytes of data. 

64 bytes from 10.244.1.7: icmp_seq=1 ttl-63 time-0.487 ms 
64 bytes from 10.244.1.7: icmp_seq=2 ttl-63 time-0.494 ms 
64 bytes from 10.244.1.7: icmp_seq=3 ttl-63 time-0.495 ms 





图 12-7 


(3) 集群 外 (192.168.56.1) 可 以 访问 Service， 如 图 12-8 所 示 。 


> ~ 
> ~ curl 192.168.56.106:30000 


<htmL><body><h1>It works! </h1i></body></htm1> 
+ ~ 





图 12-8 
现在 创建 Network Policy， 如 图 12-9 所 示 。 


kind: NetworkPolicy 
apiVersion: networking.k8s.io/vi 
metadata: 
name: access-httpd 
spec: 
podSelector: 
matchLabels: 
run: httpd (1 
ingress: 
- from: 
- podSelector: 
matchLabels: 
access: 
ports: 
- protocol: TCP 
port: 





图 12-9 


(D 定义 将 此 Network Policy 中 的 访问 规则 应 用 于 label 为 run: httpd 的 
Pod， 即 httpd 应 用 的 三 个 副本 Pod。 


(2) ingress 中 定义 只 有 1label 为 access: "true" 的 Pod 才 能 访问 应 用 。 
© 只 能 访问 80 端 口 。 
通过 kubectl apply 创 建 Network Policy， 如 图 12-10 所 示 。 


ubuntue@k8s-mastenr :~ 

ubuntuék8s-master:-$ kubectl apply -f policy.yaml 
networkpolicy "“access-httpd" created 
ubuntu@k8s-master: ~$ 


ubuntuék8s-master:-$ kubectl get networkpolicy 
NAME POD-SELECTOR AGE 

access-httpd  run=httpd 32s 
ubuntu@k8s-master: ~$ 





[12-10 


验证 Network Policy 的 有 效 性 : 


(1) busybox Pod 已 经 不 能 访问 Service， 如 图 12-11 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl run busybox --rm -ti --image=busybox /bin/sh 
If you don't see a command prompt, try pressing enter. 

/ # 


/ € wget httpd-svc:8080 --timeout=5 

Connecting to httpd-svc:8080 (10.104.77.239:8080) 
wget: download timed out 

/ # 





图 12-11 


如 果 Pod 添 加 了 label access: "true" 就 能 访问 到 应 用 ， 但 Ping 已 经 被 禁 
止 ， 如 图 12-12 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl run busybox --rm -ti|--labels-"access-true"|--image-busybox /bin/sh 
If you don't see a command prompt, try pressing ertter- 

/ # 

/ # wget httpd-svc:8080 

Connecting to httpd-svc:8080 (10.104.77.239: 8080) 

index.html 100% | A AE A koke A AH | 45 0:00:01 
/ # 

/ # ping -c 3 10.244.1.7 

PING 10.244.1.7 (10.244.1.7): 56 data bytes 


--- 10.244.1.7 ping statistics --- 
3 packets transmitted, 0 packets received, 100% packet loss 
/ # 





图 12-12 


(2) 集群 节点 已 经 不 能 访问 Service， 也 Ping 不 到 副本 Pod， 如 图 
12-13 所 示 。 


root@k8s-node2:~# 

root@k8s-node2:~# curl 10.104.77.239:8080 --connect-timeout 5 
curl: (28) Connection timed out after 5001 milliseconds 
root@k8s-node2:~# 

root@k8s-node2:~# ping -c 3 10.244.1.7 

PING 10.244.1.7 (10.244.1.7) 56(84) bytes of data. 


--- 10.244.1.7 ping statistics --- 
3 packets transmitted, @ received, 100% packet loss, time 1999ms 
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(3) 集群 外 (192.168.56.1) 已 经 不 能 访问 Service， 如 图 12-14 所 





ZN o 


> ~ 
> ~ curl 192.168.56.106:30000 --connect-timeout 5 


curl: (28) Connection timed out after 5003 milliseconds 
> ~ 





图 12-14 


如 果 和 希望 让 集群 节点 和 集群 外 〈192.168.56.1) 也 能 够 访问 到 应 
用 ， 可 以 对 Network Policy 做 如 图 12-15 所 示 的 修改 。 


kind: NetworkPolicy 
apiVersion: networking.k8s.io/v1 
metadata: 
name: access-httpd 
spec: 
podSelector: 
matchLabels : 
run: httpd 
ingress: 
- from: 
- podSelector: 
matchLabels: 
access: 


ports: 
- protocol: TCP 
port: 





图 12-15 


应 用 新 的 Network Policy， 如 图 12-16 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl apply -f policy.yaml 
networkpolicy "access-httpd" configured 
ubuntuék8s -master : ~$ 
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现在 ， 集 群 节点 和 集群 外 (192.168.5631) 已 经 能 够 访问 了 ， 如 图 
12-17、 图 12-18 所 示 。 





root@k8s-node2:~# 

root@k8&s-node2:~# curl 10.104.77.239:8080 
«html»«body»«h1»It works!«/h1»«/body»«/html- 
root@k8&s-node2:~# 





图 12-17 


> ~ 
> ~ curl 192.168.56.106:30000 


<htmL><body><h1>It works! </h1></body></htm1> 
> ~ 
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除了 通过 ingress 限 制 进入 的 流量 ， 也 可 以 用 egress 限 制 外 出 的 流 


量 。 大 家 可 以 参考 官网 相关 文档 和 示例 ， 这 里 就 不 歼 述 了 。 


12.4 ”小结 

Kubernetes 采 用 的 是 扁平 化 的 网 络 模型 ， 每 个 Pod 都 有 目 己 的 也， 并 
且 可 以 直接 通信 。 

CNI 规 范 使 得 Kubernetes 可 以 灵活 选择 多 种 Plugin 实 现 集群 网 络 。 


Network Policy 赋 子 了 Kubernetes 强 大 的 网 络 访问 控制 机 制 。 





2313= Kubernetes Dashboard 


前 面 章节 Kubermnetes 所 有 的 操作 我 们 都 是 通过 命令 行 工 具 kubectl 完 
成 的 。 为 了 提供 更 丰富 的 用 户 体验 ，Kubernetes 还 开发 了 一 个 基于 Web 
的 Dashboard， 用 户 可 以 用 Kubernetes Dashboard 部 署 容器 化 的 应 用 、 监 
控 应 用 的 状态 、 执 行 故 障 排查 任务 以 及 管理 Kubernetes 的 各 种 资源 。 


在 Kubernetes Dashboard 中 可 以 查看 集群 中 应 用 的 运行 状态 ， 也 能 够 
创建 和 修改 各 种 Kubernetes 资 源 ， 比 如 Deployment、Job、DaemonSet 
等 。 用 户 可 以 Scale Up/Down Deployment、 执 行 Rolling Update. Œ JA 3 
个 Pod 或 者 通过 向 导 部 署 新 的 应 用 。Dashboard 能 显示 集群 中 各 种 资源 的 
状态 以 及 日 志 信 息 。 


可 以 说 ，Kubernetes Dashboard 提 供 了 kubectl 的 绝 大 部 分 功能 ， 大 家 
可 以 根据 情况 进行 选择 。 








13.4 安装 


Y 


Kubernetes 默 认 没 有 部 署 Dashboard， 可 通过 如 下 命令 安装 : 


kubectl create : 
f https://raw.githubusercontent.com/kubernetes/dashboard/master/s 


dashboard. yaml 


DashboardZ:fEkube-system ”namespace 中 创建 自己 的 Deployment 和 和 
Service， 如 图 13-1 所 示 。 


ubuntuék8s-master:-$ kubectl --namespace=kube-system get deployment kubernetes-dashboard 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
kubernetes-dashboard 1 1 1 1 17h 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl --namespace=kube-system get service kubernetes-dashboard 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
kubernetes-dashboard | ClusterIP 10.110.199.111 <none> 443/TCP — 17h 


图 13-1 


为 Service 是 ClusterIP 类 型 ， 为 了 方便 使 用 ， 我 们 可 通过 kubectl -- 
namespace=kube-system edit service kubernetes-dashboard 修 改 成 NodePort 
类 型 ， 如 图 13-2 所 示 。 





spec: 
clusterIP: 10.110.199.111 
ports: 
- port: 
protocol: TCP 
targetPort: 


selector: 
k8s-app: kubernetes-dashboard 


sessionAffinity: None 
type: NodePort 
status: 


LoadBalancer: {} 
图 13-2 





保存 修改 ， 此 时 已 经 为 Service 分 配 了 端口 31614， 如 图 13-3 所 示 。 


ubuntuek8s master : ~$ 
ubuntu@k8s-master:~$ kubectl --namespace-kube-system get service kubernetes-dash| 





NAME TYPE CLUSTER- IP EXTERNAL - IP PORT(S 
kubernetes-dashboard NodePort 10.110.199.111 «none» 443:31614/TCP 
ubuntuék8s-master : ~$ 
图 13-3 
WA: HH p 
通过 浏览 


# 访 问 Dashboard https://192.168.56.105:31614/， 登 录 界 面 
如 图 13-4 所 示 。 


Kubernetes Dashboard 


Authentication method: 
(8) Kubeconfig 
O Token 


Kubeconfig YAML file * = 


SIGN IN SKIP 
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13.2 ”配置 登录 权限 


Dashboard 支 持 Kubeconfig 和 Token 两 种 认证 方式 ， 为 了 简化 配置 ， 
我 们 通过 配置 文件 dashboard-admin.yaml 为 Dashboard 默 认 用 户 赋 予 admin 
权限 ， 如 图 13-5 所 示 。 


apiVersion: rbac.authorization.k8s.io/vibetal 
kind: ClusterRoleBinding 
metadata: 
name: kubernetes-dashboard 
labels: 
k8s-app: kubernetes-dashboard 
roleRef: 


apiGroup: rbac.authorization.k8s.io 
kind: ClusterRole 
name: cluster-admin 

subjects: 

- kind: ServiceAccount 
name: kubernetes-dashboard 
namespace: kube-system 





图 13-5 


执行 kubectl apply 使 之 生效 ， 如 图 13-6 所 示 。 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ kubectl apply -f dashboard-admin.yaml 


clusterrolebinding "kubernetes-dashboard" created 
ubuntu@k8s-master : ~$ 





图 13-6 


现在 直接 单 击 登录 页 面 中 的 SKIP 就 可 以 进入 Dashboard 了 ， 如 图 13- 
7 所 示 。 





kubernetes Q Search 


= Overview 








Cluster 
Services 
Namespaces 
Nodes ame 一 abels uster nternal endpoints 
lot N T Label cl IP | | endpoii 
Persistent Volumes component: apiserver ^ 
© kubernetes 10.96.0.1 Kors dan 
Roles provider: kubernetes kubernetes:0 TCP 
Storage Classes 
Secrets 
Namespace 
defaut > Name $ Type 
Overview default-token-cx5xr kubernetes.io/service-account-token 
Workloads 


Daemon Sets 
Deployments 

Jobs 

Pods 

Replica Sets 
Replication Controllers 


Stateful Sets 
Discovery and Load Balancing 


Ingresses 


Services 





图 13-7 


13.3 Dashboard 7i iti Zi (4 


Dashboard 的 界面 很 简洁 ， 分 为 三 个 大 的 区 域 。 
CD 顶部 操作 区 ， 如 图 13-8 所 示 。 在 这 里 用 户 可 以 搜索 集群 中 的 
© kubernetes Q search + oneare | B 
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(2) 左边 导航 菜单 。 通 过 导航 菜单 可 以 查看 和 管理 集群 中 的 各 种 
资源 。 沫 单项 按照 资源 的 层级 分 为 以 下 两 类 : 














e Cluster 级 别 的 资源 ， 如 图 13-9 所 示 。 
Cluster 


Namespaces 
Nodes 

Persistent Volumes 
Roles 


Storage Classes 
图 13-9 


e Namespace 级 别 的 资源 ， 如 图 13-10 所 示 。 


Namespace 


default 


Overview 


Workloads 


Daemon Sets 
Deployments 

Jobs 

Pods 

Replica Sets 
Replication Controllers 


Stateful Sets 
Discovery and Load Balancing 


Ingresses 


Services 
Config and Storage 


Config Maps 
Persistent Volume Claims 


Secrets 
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默认 显示 的 是 default Namespace， 可 以 进行 切换 ， 


如 图 13-11 所 示 。 


(3) 中 间 主 体 区 。 


在 导航 沫 单 中 单 击 了 东 类 资 


All namespaces 


NAMESPACES 


default 


kube-public 


kube-system 


图 13-11 


源 ， 中 间 主 体 区 就 会 


显示 该 





例 ， 比 如 单 击 Pods， 如 图 13-12 所 示 。 


Pods 


(HE EE EE AE EE EE EE EE EE < BE EE < 


Name $ 


kubernetes-dashboard-747c4f7cf-wwiz7 


kube-proxy-jch75 
kube-flannel-ds-f7wgk 
kube-flannel-ds-Injqt 
kube-proxy-9cggh 
kube-flannel-ds-bgclx 
kube-apiserver-k8s-master 
kube-scheduler-k8s-master 
etcd-k8s-master 
kube-controller-manager-k8s-master 
kube-dns-545bc4bfd4-6zr5w 


kube-proxy-q6j8m 


Node Status $ 
k8s-node1 Running 
k8s-node1 Running 
k8s-node1 Running 
k8s-node2 Running 
k8s-node2 Running 
k8s-master Running 
k8s-master Running 
k8s-master Running 
k8s-master Running 
k8s-master Running 
k8s-master Running 
k8s-master Running 


图 13-12 


Restarts 


Age * 

18 hours 
18 hours 
18 hours 
18 hours 
18 hours 
18 hours 
18 hours 
18 hours 
18 hours 
18 hours 
18 hours 


18 hours 


13.4 典型 使 用 场景 


接 下 来 我 们 介绍 几 个 Dashboard 的 典型 使 用 场景 。 


13.4.1 a Deployment 


单 击 顶部 操作 区 的 +CREATE 按 钮 ， 如 图 13-13 所 示 。 


Deploy a Containerized App 


© Specify app details below 


© Upload a YAML or JSON file 


1 


None 
v SHOW ADVANCED OPTIONS 


CANCEL 
[13-13 
用 户 可 以 直接 输入 要 部 署 应 用 的 名 字 、 镜 像 、 副 本 数 等 信息 ， 也 可 
以 上 传 YAML 配 置 文件 。 如 果 是 上 传 配置 文件 ， 则 可 以 创建 任意 类 型 的 
资源 ， 而 不 仅仅 是 Deployment。 


13.4.2 ”在 线 操作 





对 于 每 种 资源 ， 都 可 以 单 击 按钮 执行 各 种 操作 ， 如 图 13-14 所 示 。 


Deployments 


Name > Namespace Labels s Age $ Images 


o9 kubernetes-dashboard kube-system k8s-app: kubernetes-das.. 18 hours gcr.io/google containers/k 


gcr.io/google_containe 
o kube-dns kube-system k8s-app: kube-dns 18 hours gcr.io/google_containe Scale 
gcr.io/google containe 





Delete 


View/edit YAML| 





图 13-14 


例如 ， 单 击 View/edit YAML， 可 直接 修改 资源 的 配置 ， 保 存 后 立即 
生效 ， 其 效果 与 kubectl edit 一 样 ， 如 图 13-15 所 示 。 


Edit a Deployment 


powered by ace 





1 

2 "kind": "Deployment", | 

3 "apiVersion": "extensions/vlbetal", 

4 "metadata": { J 

5 "name": "kube-dns", 

6 "namespace": "kube-system", 

$ "selfLink": "/apis/extensions/vlbetal/namespaces/kube-system 
/deployments/kube-dns", 

8 "uid": "a676a020-c2c9-11e7-abb6-0800274451ad", 

9 "resourceVersion": "33294", 

10 "generation": 1, 

TI "creationTimestamp": "2017-11-06T08:08:192", 

12+ "labels": { 

13 "k8s-app": "kube-dns" 

14 be 

15+ "annotations": { 

16 "deployment.kubernetes.io/revision": "1" 

17 } 

18 - 

19+ "spec": { 

20 "replicas": 1, 

21+ "selector": { 

22» "matchLabels": { 

23 "k8s-app": "kube-dns" 

24 } 

25 be 

267 "template": { 

27» "metadata": { 

28 "creationTimestamp": null, 

29) "labels": { 











CANCEL COPY UPDATE 
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13.43 ”查看 资源 详细 信息 


单 击 某 个 资源 实例 的 名 字 ， 可 以 查看 详细 信息 ， 


其 效果 与 kubectl 


describe 一 样 ， 如 图 13-16 所 示 。 


Details 


Name: kube-dns 
Namespace: kube-system 
Labels: k8s-app: kube-dns 
Selector: k8s-app: kube-dns 
Strategy: RollingUpdate 

Min ready seconds: 0 


Revision history limit: Not set 


Rolling update strategy: Max surge: 10%, Max unavailable: 0 


Status: 1 updated, 1 total, 1 available, 0 unavailable 


Status 


New Replica Set 


Name Namespace 


@ kube-dns-545bc4bfd4 kube-system 


Old Replica Sets 


13.4.4 


Labels Pods Age Images 


gcr.io/google. containers/k 
gcr.io/google. containers/H 
gcr.io/google containers/k 


k8s-app: kube-dns 
au 18 hours 
pod-template-hash: 101... 


There is nothing to display here 
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查看 Pod Flos Tun 


在 Pod 及 其 父 资 源 (DaemonSet、ReplicaSet 等 ) 页 面 单 击 三 按钮， 
可 以 查看 Pod 的 日 志 ， 其 效果 与 kubectl logs 一 样 ， 如 图 13-17 所 示 。 


Logs from kube-flannel 


.639451 
.640318 
.640365 
- 658718 
- 650800 
.651546 
-651575 
-651580 
.651795 
-651863 
-659647 
659714 
659781 
-659815 


Pss of default interface 
name enp@s3 and address 
address to interface add 

bde controller to sync 
manager 

kube.go:137] Node controller syne successful 

main.go:235] Created subnet manager: Kubernetes Subnet Ma 

main.go:238] Installing signal handlers 

main.go:348] Found network config - Backend type: vxlan 

vxlan.go:119] VXLAN config: VNI=1 Port=@ GBP=false DirectR 

main.go:295] Wrote subnet file to /run/flannel/subnet.env 

main.go:299] Running backend. 

main.go:317] Waiting for all goroutines to exit 

vxlan network.go:56] watching for new subnet leases 


kube-flannel-ds-f /wgk 


kube-flannel-ds-Injqt 


Logs from 11/6/17 8:09 AM to 11/6/17 8:09 AM 





图 13-17 


Kubernetes Dashboard 界 面 设计 友好 ， 自 解释 性 强 ， 可 以 看 作 GUI 版 
的 kubectl， 更 多 功能 留 给 大 家 自己 探索 。 


13.5 小结 


本 章 介 绍 了 Kubernetes Dashboard 的 安装 和 使 用 方法 。Dashboard 能 
完成 日 党 管理 的 大 部 分 工作 ， 可 以 作为 命令 行 工 具 kubect 的 有 益 补 充 。 
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i!) £&Kubernetesf& FF If a Aas LL RR. — B SES TT 
起 来 ， 我 们 需要 确保 集群 一 起 都 是 正常 的 ， 所 有 必要 组 件 就 位 并 各 司 其 
职 ， 有 足够 的 资源 满足 应 用 的 需求 。Kubernetes 是 一 个 复杂 系统 ， 运 维 
团队 需要 有 一 套 工具 帮助 他 们 获知 集群 的 实时 状态 ， 并 为 故障 排查 提供 
及 时 和 准确 的 数据 文 持 。 


本 章 重 点 讨论 Kubernetes 常 用 的 监控 方案 ， 下 一 章 会 讨论 日 志 管 
理 。 








14.1 Weave Scope 


Weave ”Scope 是 Docker 和 Kubernetes 可 视 化 监控 工具 。Scope 提 供 了 
自 上 而 下 的 集群 基础 设施 和 应 用 的 完整 视图 ， 用 户 可 以 轻松 对 分 布 式 的 
容器 化 应 用 进行 实时 监控 和 问题 诊断 。 


14.1.1 安装 Scope 


安装 Scope 的 方法 很 简单 ， 执 行 如 下 命令 : 


kubectl apply --namespace kube-system - 
E "https://cloud.weave.works/k8s/scope.yaml?k8s- 
version-$(kubectl version | base64 | tr -d '\n')" 


部 署 成 功 后 ， 有 如 图 14-1 所 示 的 相关 组 件 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get --namespace=kube-system daemonset weave-scope-agen 
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SEL 
weave-scope-agent 3 3 3 3 3 <none> 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace-kube-system deployment weave-scope-app 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 

weave-scope-app 1 1 1 1 18h 

ubuntuék8s master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace-kube-system service weave-scope-app 


NAME TYPE CLUSTER- IP EXTERNAL-IP PORTCS) AGE 
weave-scope-app NodePort 10.106.149.68 <none> 80: 30693/TCP 18h 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace-kube-system pod | grep weave 
weave-scope-agent-765g2 1/1 Running 0 18h 


weave-scope-agent-nchjr 1/1 Running 0 18h 
weave-scope-agent-wnzn4 1/1 Running @ 18h 
weave-scope-app-567cfdb6d5-kk2cg 1/1 Running 0 18h 
ubuntu@k8s-master : ~$ 





图 14-1 


(1) DaemonSet “weave-scope-agent， 集 群 每 个 节点 上 都 会 运行 的 
scope agent 程 序 ， 人 负责 收集 数据 。 


(2) Deployment weave-scope-app，Sscope 应 用 ， 从 agent 获 取 数 据 ， 
通过 Web UI 展示 并 与 用 户 交 互 。 


(3) Service weave-scope-app， 默 认 是 ClusterIP 类 型 ， 为 了 方便 ， 
已 通过 kubectl edit 修 改 为 NodePort。 


14.1.2 {EH Scope 





浏览 器 访问 http:/192.168.56.106:30693/，Scope 默 认 显示 当前 所 有 的 
Controller (Deployment、DaemonSet 等 ) ， 如 图 14-2 所 示 。 





e. e LA Weave Scope + 
€ 192.168.56.106:30693 GQ Search 
2 weavescope Q SEARCH PROCESSES CONTAINERS PODS HOSTS *$ GRAPH E TABLE 


BY DNS NAME CONTROLLERS WEAVE NET 


BY IMAGE SERVICES 


e e LJ 
kube-dns kube-flannel-ds kube-proxy 
Deployment of 1 pod DaemonSet of 3 pods DaemonSet of 3 pods 
e e e 


kubernetes-dashboa.. weave-scope-agent weave-scope-app 
Deployment of 1 pod DaemonSet of 3 pods Deployment of 1 pod 


6 NODES (4 FILTERED) 





图 14-2 


1. 拓扑 结构 


Scope 会 目 动 构建 应 用 和 集群 的 逻辑 拓扑 ， 比 如 单 击 顶 部 PODS， 会 
显示 所 有 Pod 以 及 Pod 之 间 的 依赖 关系 ， 如 图 14-3 所 示 。 


eso (yx 


^u 


Weave Scopo 














i) | 192.168.56.106:30693/#!/state/{"controlPipe” :null,"nodeDetails”:[],"topologyViewMode":"topo’,"pinnedMetricType":null,"pinnedSear 











C | Q Search 
L2 weavescope Q SEARCH PROCESSES ^ CONTAINERS | PODS HOSTS M GRAPH = TABLE 
BY NAME BY DNS NAME CONTROLLERS  WEAVENET CPU Memory 
BY IMAGE SERVICES 
()—()—(0 GC) © © ©) ©) (0 (C) 
kubescheduerk8.. kube-proxy-o6j@m —_weeve-scope-agent... kube-flannel-ds.‘7w.... kube-flannel-ds-Injgt weave-scope-agert.... kubecontrolerman. kube-proxyjch75 _ kubemetes dashboe.. — kubeproxyócggh 
1 contaner container Temare — —. Tenaher enane fconaner 一 1 container 1 eontener 1 container "container 
~ 
20 
Kubecapiserver 
tod KBs master 
kubedns-545bcábf.. kube-flannelds-bgclx 
e. . 
wemveocopeagent.. weave scope ip 5... 
16 NODES (4 FILTERED) 
Show Unmanaged Hide Unmanaged 
default kube-system All Namespaces 


图 14-3 


单 击 HOSTS， 会 显示 各 个 节点 之 间 的 关系 ， 如 图 14-4 所 示 。 


PROCESSES CONTAINERS 


BY NAME BY DNS NAME 


BY IMAGE 


10.41% 


k8s-master 


` 


PODS 


CONTROLLERS 


SERVICES 


5.15% | 


k8s-nodel ~~ 


5.20% 


x SET 
k8s-node2 =| 


| / 


/ j 
/ 


M 
Y x 


C) 


The Internet 


VERSION 1.6.5 ON weave-scope-app-567cfdb6ds-kk2cg 


HOSTS 


WEAVE NET 


图 14-4 
2. 实时 资源 监控 
可 以 在 Scope 中 查看 资源 的 CPU 和 内 存 使 用 情况 ， 如 图 14-5 所 示 。 


CPU X Memory 


图 14-5 


支持 的 资源 有 Host、Pod 和 Container， 如 图 14-6、 图 14-7 所 示 。 


353.5MB 
"- 
k8s-node1 — 
| 1 


I 


470.7MB \ 
"-— h 
k8s-node2 ~~ | 


| r4 | 
| | 
| M | 
783.3MB 
k8s-master | 


A 


The Internet 
Outbound connections 


图 14-6 


0.33% 


NX 
etcd-k8s-master 
1 container 


0.69% 


kube-apiserver- 


k8s-master 
1 container 
图 14-7 


3. 在 线 操作 


Scope 还 提供 了 便捷 的 在 线 操作 功能 ， 比 如 选中 东 个 Host， 单 击 >_ 
按钮 可 以 直接 在 浏览 器 中 打开 节点 的 命令 行 终端 ， 如 图 14-8 所 示 。 





M weave Scope - kas-master x \ + 











192.168.56.106:3 controlPipe":{"id":"pi adel e *6uU$40 
% weavescope Q SEARCH PROCESSES CONTAINERS PODS HOSTS GRAPH ESTABLE | lai LIVE T 
BY NAME BY DNS NAME CONTROLLERS WEAVE NET cPUR (im) M 


RVI 








BY IMAGE SB 











rooték8s-master:/# su - ubuntu 

ubuntuék8s-master:-$ 

wbuntuék8s-master:-$ kubectl get nodes 

NAME STATUS ^ ROLES AGE 

k8s-master Ready master 24 

Xk8s-nodel Ready <none> — 2a 

k8s-node2 Ready <none> 2d 

ubuntuék8s-master:-$ M 0.75 


CPU MENORY LOAD (1M) 





KERI 


VERSION: 4.4.0-98-generic #121-Ubuntu SMP Tu... 
UPTIME: 10h13m40s 








D ORT v# 
k8s-master 2379 62 
k8s-master 10255 15 
k8s-master 6443 11 
k8s-node1 6443 5 
k@e-node? 6442 4 
k8s-master 2379 62 
k8s-master 10255 15 











图 14-8 


单 击 Deployment 的 + 可 以 执行 Scale Up 操作 ， 如 图 14-9 所 示 。 


kubernetes-dashboard 


-四 


STATUS 





0.00 % 33.4MB 


CPU MEMORY 


INFO 


TYPE: Deployment 
NAMESPACE: kube-system 
CREATED: 3 days ago 
OBSERVED GEN.: 5 
DESIRED REPLICAS: 1 
#PODS: 1 
STRATEGY: RollingUpdate 


PODS STATE # IP 
kubernetes-dashbo... Running 1 10.244.2.3 








CONTAINERS v CPU MEMORY 

kubernetes-dashboard 0.00% 33.4 MB 

PROCESSES PID v CPU MEMORY 

Idachhnard 9091 n nn 9. 20 R MR 
图 14-9 


查看 Pod 的 日 志 ， 如 图 14-10 所 示 。 





Weave Scope - etcd-k8s. + 


ej 


192.168.56.106:30€ 


% weavescope Q SEARCH 


2017-11-09701:47:37.6085951342 2017-11-09 0 
(took 838.99148) 
2017-11-09701:47:43.5405393842 2017-11-09 01 
925ma for 1 entries) 
2017-11-09701:47:43.5406069842 2017-11-09 01 
ete range! 
2017-11-09701:52 
2017-11-09701:52 
(took 599.34445) 
2017-11-09701:57:37.6154125252 2017-11-09 01 
2017-11-09701:57:37.615441133 2017-11-09 0 
took 766.6528) 
2017-11-09702:02:37.6216172052 2017-11-09 02 
2017-11-09702:02:37.6216430497 2017-11-03 02 
(took 1.004655ms) 
2017-11-09702:07:37.6237256477 2017-11-09 02 
07:37.6248401892 2017-11-09 02 


37.6114601792 2017-11-09 01 
37.611492261z 2017-11-09 01 


2017-11-09T02 
(took 870.7p8 
2017-11-09702:12:37.628508032 2017-11-09 0; 
2017-11-09702:12:37.6295704512 2017-11-09 02 
(took 742.77545) 
2017-11-09702:17:37. 
2017-11-09702:17:37. 
(took 810.49348) 
2017-11-09702:22:37.637647662 2017-11-09 02 
2017-11-09T02 
(took 644.826us) 


024735 
994489% 2017-11-09 02 


2017-11-09 02: 


2:37.6387561812 2017-11-09 02:2 


Q 








7.608422 finished scheduled compaction at 120261 


147143.540242 etcdserver: apply entries took too long [10.31 


£47243,540263 etcdserver: avoid queries with large range/del 
52:37.610313 


52237.611149 


mvcc: store.index: compact 120650 


mvce: finished scheduled compaction at 120650 


157:37.614172 T 


1131.615226 I 


mvcet store.index: compact 121040 


| mvcc: finished scheduled compaction at 121040 ( 
19913 1 


37.621258 T 


mvcc: store.index: compact 121430 


mvcc: finished scheduled compaction at 121430 
7.623263 1 


7.624528 1 


mvce: store.index: compact 121819 


mvce: finished scheduled compaction at 121819 
1.628217 I 


:12:37.629386 1 


| mvcc: store.index: compact 122210 


mvcc: finished acheduled compaction at 122210 


17237.633778 1 | mvec: 122599 


17:37.634924 1 


store.index: compact 


mvcc: finished scheduled compaction at 122599 


7.637475 I | mvec: store.index: compact 122988 


7.638648 I finished scheduled compaction at 122988 











etcd-k8s-master 
k89-master 








182.3 MB 





ATE Running 


192.168.56.105 


NTAINERS: 1 





kube-system 
3 days ago 
#1 





2379 54 

2379 6 

2379 6 
co 








3 








可 以 查看 attach、restart、stop 容 器 ， 以 及 直接 在 Scope 中 排查 问题 ， 


如 图 14-11 所 示 。 


图 





14-10 


kubedns 


google_containers/k8s-d... k8s-master 
kube-dns-545bc4bfd4-62... 


cocum 


STATUS 


28 MB 


MEMORY 


IMAGE: gcr.io/google. containers/k8s-dns-kub... 
COMMAND: /kube-dns —domain=cluster.local. -dn... 
STATE: Up 19 hours 
UPTIME: 19h42m55s 
RESTART #: O 
NETWORKS: none 
IPS: 
PORTS: 
CREATED: 20 hours ago 


PROCESSES PID vCPU MEMORY 
/kube-dns 3613 0.00% 22.3 MB 





图 14-11 
4. 强大 的 搜索 功能 


Scope 支 持 关 键 字 搜索 和 定位 资源 ， 如 图 14-12 所 示 。 还 可 以 进行 条 
件 搜索 ， 比 如 查找 和 定位 MEMORY 大 于 100MB 的 Pod， 如 图 14-13 所 


























| Q prox ] [ PROCESSES | f CONTAINERS | | PODS JU HOSTS «GRAPH Œ TABLE 
Try "etcd-k8s-mas", [CONTROLLERS | 
nus EN aan BY NAME BY DNS NAME | CONTROLLERS WEAVE NET CPUX Memory 
enter to apply the search as a | BEIMAGE J SERVIGES. 
filter, @ 

e e * 
kube-proxy-qojam kube-proxy-Jcn75 kube-proxy-scggh 
macro MERE der perum 

14-12 
| Q MEMORY > 100M | | PROCESSES | | CONTAINERS | | PODS | | HOSTS 
Try "etcd-k8s-mas', BY NAME BY DNS NAME | CONTROLLERS WEAVE NET 
"state:running", or "cpu > 2%". Hit 
enter to apply the search as a BY IMAGE SERVICES 
filter. [?) 
102.7MB 
weave-scope- i Det 
agent-765g2 
1 container 
加 、 
246.9MB 
= 
kube-apiserver-k8s-... 
1 container 
e 
-— 
etcd-k8s-master 
1 container 
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ao Scope 界 面 极其 友好 ， 操 作 简 清流 畅 ， 更 多 功能 留 给 大 家 去 
WA. 


14.2 Heapster 


Heapster 是 Kubernetes 原 生 的 集群 监控 方案 。Heapster 以 Pod 的 形式 
运行 ， 它 会 自动 发 现 集群 节点 ， 从 节点 上 的 Kubelet 获 取 监 控 数 据 。 
Kubelet 则 是 从 节点 上 的 cAdvisor 收 集 数 据 。 


Heapster 将 数据 按照 Pod 进 行 分 组 ， 将 它们 存储 到 预先 配置 的 
backend 并 进行 可 视 化 展示 。Heapster 当 前 支持 的 backend 有 InfluxDB QM 
过 Grafana 展 示 ) 、Google Cloud Monitoring 等 。Heapster 的 整体 架构 如 
图 14-14 所 示 。 














下 面 我 们 将 实践 由 Heapster、InfluxDB 和 Grafana 组 成 的 监控 方案 。 
Kubelet 和 cAdvisor 是 Kubernetes 的 自 带 组 件 ， 无 须 额 外 部 署 。 


14.2.1 HE 


a 





HeapsterZk £r z —^Kubernetes HH, MEDIR, ZIU Pi 
A 
La 


git clone https://github.com/kubernetes/heapster.git 

kubectl apply -f heapster/deploy/kube-config/influxdb/ 

kubect1 apply -f heapster/deploy/kube-config/rbac/heapster- 
rbac.yaml 


Heapster 相 关 资 源 如 图 14-15 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntuGk8s-master:-$ kubectl get --namespace-kube-system deployment | grep -e heapster -e monitor 
heapster 1 ih 8m 

monitoring-grafana 1 1 8m 

moni toring-influxdb 1 $ 8m 

ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get --namespace=kube-system service | grep -e heapster -e monitor 

heapster ClusterIP 10.108 .228.4 <none> 80/TCP 

monitoring-grafana NodePort 10.111.8.115 <none> 80:32314/TCP 

monitoring-influxdb ClusterIP — 10.99.44.147 «none» 8086/TCP 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace-kube-system pod -o wide | grep -e heapster -e monitor 
heapster-5d67855584-5hdqn Running 8m 10.244.1.18 k8s-node2 
moni toring-grafana-5bccc9f786-5bbkw Running 8m 10.244.2.13 k8s-node1 
monitoring-influxdb-85cb4985d4-t2b26 1/1 Running 8m 10.244.2.14 k8s-node1 


ubuntu@k8s-master : ~$ 
图 14-15 








为 了 便于 访问 ， 已 通过 kubectl edit 将 Service monitoring-grafana 的 类 
型 修改 为 NodePort。 


14.2.2 ”使 用 


浏览 器 打开 Grafana 的 Web UI: http://192.168.56.105:32314/。 


Heapster 己 经 预先 配置 好 了 Grafana 的 DataSource 和 Dashboard， 如 图 
14-16 AN 6 


Grafana - Home 


€ 192.168.56.105 


Gy 24 Home. & 


Home Dashboard 


Getting Started with Grafana 


© © © 


Install Grafana Create your first data source Create your first dashboard 


Starred dashboards 


Recently viewed dashboards 
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单 击 左 上 角 的 Home 某 单 ， 可 以 看 到 预定 义 的 Dashboard ”Cluster 和 
Pods， 如 图 14-17 所 示 。 


(9 M Q,  Finddashboards by name 


| @ Home 


ss Cluster 


ss Pods 





图 14-17 


单 击 Cluster， 可 以 查看 集群 中 节点 的 CPU、 内 存 、 网 络 和 磁盘 的 使 
用 情况 ， 如 图 14-18 所 示 。 


e ) vA 


Grafana - Cluster + 








€ 192.168.56.105:323 14 





L^ Cluster- C Ð ME 
k8s-master ~ 


Overall Cluster CPU Usage 


09:38 09:40 09:42 09:44 09:46 09:48 


CPU Usage by Node 


300 
250 
$ 200 
g 
= 150 
100 
50 


0 
09:32 09:34 09:36 09:38 09:40 09:42 09:44 09:46 


09:48 09:50 
一 Usage k8s-master == Usage k8s-nodel 一 Usage k8s-node2 = Limit k8s-master Limit k8s-node1 Limit k8s-node2 


Individual CPU Usage: k8s-master 
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TEZc ELAR ESA AB, 814-198 Tz. 


49 - @@Cluster- © 


nodename 


k8s-master 
1.0K k8s-node1 


800 —— k8s-node2 
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切换 到 Pods Dashboard， 可 以 查看 Pod 的 监控 数据 ， 包 括 单 个 Pod 的 
CPU、 内 存 、 网 络 和 磁盘 使 用 情况 ， 如 图 14-20 所 示 。 


hd 1 Grafana - Pods 


€ 192.168.56.105 


S8 Pods- (€? = 


namespace kube-system ~ podname etcd-k8s-master ~ 


Individual CPU Usage: kube-system etcd-k8s-master 


Millicores 


09:34 09:36 09:38 09:40 09:42 09:44 09:46 09:48 09:50 


== Usage kube-system etcd-k8s-master etcd == Limit kube-system etcd-k8s-master etcd == Request kube-system etcd-k8s-master etcd 


Individual Memory Usage: kube-system etcd-k8s-master 
238 MiB 
191 MiB 
143 MiB 
95 MiB 
48 MiB 
0B 
09:42 09:44 09:46 09:48 09:50 09:52 


09:34 09:36 09:38 09:40 
* Usage kube-system etcd-k8s-master etcd == Limit kube-system etcd-k8s-master etcd == Request kube-system etcd-k8s-master etcd == Working Set 


Individual Network Usage: kube-system etcd-k8s-master 


100 kBps 
80 kBps 
60 kBps 


40 kBps 
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在 左上 角 可 以 切换 到 不 同 Namespace 的 Pod， 如 图 14-21 所 示 。 


namespace kube-system ~ podname | 


etcd-k8s-master 
heapster-5d67855584-5hdqn 
kube-apiserver-k8s-master 
kube-controller-manager-k8s-master 
kube-dns-545bc4bfd4-jzh4c 
kube-flannel-ds-bgclx 


P] 
go 
= 
fe) 

e 

= 


kube-flannel-ds-f7wgk 


09:34 09:36 0938 Kube-flannel-ds-Injqt 


— Usage kube-system etcd-k8s-master etcd = kube-proxy-9cggh 
kube-proxy-jch75 
SERINE kube-proxy-q6j8m 


kube-scheduler-k8s-master 


191 MiB 
kubernetes-dashboard-747c4f7cf-wwlz7 


oii 
rou monitoring-grafana-5bccc9f786-5bbkw 


图 14-21 


Heapster 预 定义 的 Dashboard 很 直观 ， 也 很 简单 。 如 有 必要 ， 可 以 在 
Grafana 中 定义 自己 的 Dashboard， 满 足 特 定 的 业务 需求 。 





14.3 Prometheus Operator 


前 面 我 们 介绍 了 Kubernetes 的 两 种 监控 方案 ， 即 Weave Scope 和 
Heapster， 它 们 主要 的 监控 对 象 是 Node 和 Pod。 这 些 数据 对 Kubernetes 运 
维 人 员 是 必需 的 ， 但 还 不 够 。 我 们 通常 还 希望 监控 集群 本 身 的 运行 状 
态 ， 比 如 Kubernetes 的 API Server、Scheduler、Controller Manager 等 管理 
组 件 是 否 正常 工作 以 及 负荷 是 否 过 大 等 。 


本 节 我 们 将 学 习 监 控 方 案 Prometheus Operator， 它 能 回答 上 面 这 些 
问题 。 





Prometheus Operator 是 CoreOS 开 发 的 基于 Prometheus 的 Kubernetes 监 
控 方案 ， 也 可 能 是 目前 功能 最 全 面 的 开源 方案 。 我 们 先 通 过 截图 了 解 一 
FERTA: 

Prometheus Operator 通过 Grafana 展 示 监 控 数 据 ， 预 定义 了 一 系列 的 
Dashboard， 如 图 14-22 上 所 示 。 


Q, Find dashboards by name 


| #@ Home 


ss Deployment 

s» Kubernetes Capacity Planning 
se Kubernetes Cluster Health 

se Kubernetes Cluster Status 

ae Kubernetes Control Plane Status 
se Kubernetes Resource Requests 
s= Nodes 


sa Pods 
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。 Kubernetes 和 集群 的 整体 健康 状态 如 图 14-23 所 示 。 


Og - . B Kubernetes Cluster Health - 


Control Plane Components Down Alerts Firing Alerts Pending 


Everything UP and 


healthy 


Node Not Ready Node Disk Pressure lode Memory Pressure 





图 14-23 


e 整个 集群 的 资源 使 用 情况 如 图 14-24、 图 14-25 所 示 。 


BB Kubernetes Capacity Planning ~ v? € zoomout > © Last 15 minutes 


Idle CPU System Load 


0% 
1032 1034 1036 
load 1m —load5m — load 15m 


Memory Usage Memory Usage 
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34 0 
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Network Received Network Transmitted 
234 KiB 459 KiB 


zn 
229 KiB 449 KiB 
225 KiB 
20 KiB 439 KiB 
215 KiB 430 KiB 
210 KiB 
420 KiB 


205 KiB 


200 KiB 410 KiB 
1 1032 


0:32 10:34 10:36 10:38 10:40 1042 10:44 
-0 Li] 


Cluster Pod Utilization Pod Utilization 


1032 1033 1034 1036 1037 


— Current number of Pods = Maximum capacity of pods 





图 14-25 


。 Kubernetes 各 个 管理 组 件 的 状态 如 图 14-26、 图 14-27 所 示 。 


JQ- 由 Kubernetes cluster Status - < zomout > Olastéhours C 


Cluster Health 


Control Plane UP Alerts Firing 


UP 0 


Control Plane Status 


API Servers UP Controller Managers UP Schedulers UP Crashlooping Control Plane Pods 


0 


v Capacity Planning 


CPU Utilization Memory Utilization Filesystem Utilization Pod Utilization 
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IGEME kubernetes Control Plane Status - 从 < memos > @last15 minutes © 


API Servers UP Controller Managers UP Schedulers UP API Server Request Error Rate 


API Server Request Latency 


No data points 


End to End Scheduling Latency API Server Request Rates 


No data points 
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e 节点 的 资源 使 用 情况 如 图 14-28 所 示 。 


24 Nodes - 


server 192.168.56.107: 


Idle CPU 


cpu usage 


10:24 10:26 1028 1030 1032 5 10:40 2 10:46 10:50 
— cpuo 


Memory Usage 


0B 
10:24 10:26 10:28 10:30 


一 memoryused — memory buffers = memory cached — memory free 


Disk I/O 


iw 


WU NS L— wu —— - 


10:24 10:26 10: 10:30 10:32 10:34 10:36 
一 read 一 written 


OB 


Network Received 


10:24 10:26 10:28 10:30 10:32 10:34 10:36 10:38 10:40 10:42 10:44 10:46 10:48 10:50 10:52 


一 cni0 一 docker0 一 enp0s3 一 enp0s8 enp0s9 fannel.1 veth9fd45ed0 vethbde1df37 一 vethc0798465 — vethd65ef9a1 vethda48a512 
vethde900847 virbr0 virbrO-nic 
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< ZoomOut > @Last 30 minutes 


System Load 
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- load 1m —load5m = load 15m 


Memory Usage 
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。 Deployment 的 运行 状态 如 图 14-29 所 示 。 


49 - ZZ Deployment ~ 
Namespace monitoring ~ Deployment prometheus-operator-prometheus-operator ~ 


CPU 


0.0005 7 cores 0.04. 


Desired Replicas Available Replicas 


Replicas 


10:26 10:28 10:30 10:32 


— current replicas — available — unavailable — updated desired 


图 14-29 





e Pod 的 运行 状态 如 图 14-30 所 示 。 


{9 - 器 Pods- © ha 


Namespace All ~ Pod weave-scope-app-567cfdb6d5-kk2cg ~ Container All ~ 
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这 些 Dashboard 展 示 了 从 集群 到 Pod 的 运行 状况 ， 能 够 帮助 用 户 更 好 
地 运 维 Kubernetes， 而 且 Prometheus Operator 迭 代 非 常 快 ， 相 信 会 继续 开 
发 出 更 多 更 好 的 功能 ， 所 以 值得 我 们 花 些 时 间 学 习 和 实践 。 


14.3.1 ”Prometheus 架构 


为 Prometheus ”Operator 是 基于 Prometheus 的 ， 所 以 我 们 需要 先 了 
解 一 下 Prometheus。 


Prometheus 是 一 个 非常 优秀 的 监控 工具 。 人 准确 地 说 应 该 是 监控 方 











E. Prometheushe tt f AIER, Fel, ABER. AMIGA Esci 


Zo 


的 解决 方案 。Prometheus 的 架构 如 图 14-31 所 示 。 
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图 14-31 








官网 上 的 原始 染 构图 比 上 面 这 张 要 复杂 一 些 ， 为 了 避免 注意 力 分 
散 ， 这 里 只 保留 了 最 重要 的 组 件 。 





1. Prometheus Server 

Prometheus Server 负 责 从 Exporter 拉 取 和 存储 监控 数据 ， 并 提供 一 套 
灵活 的 查询 语言 (PromQL) 供用 户 使 用 。 

2. Exporter 


Exporter 负 责 收集 目标 对 象 (host、container 等 ) 的 性 能 数据 ， 并 通 
过 HTTP 接 口供 Prometheus Server 获 取 。 

3. 可 视 化 组 件 

监控 数据 的 可 视 化 展现 对 于 监控 方案 至 关 重 要 。 以 前 Prometheus 自 
己 开发 了 一 套 工 具 ， 不 过 后 来 废弃 了 ， 因 为 开源 社区 出 现 了 更 为 优秀 的 
产品 Grafana。Grafana 能 人 够 与 Prometheus 无 绛 集成， 提供 完美 的 数据 展示 


eu 
H5 o 








4. Alertmanager 


用 户 可 以 定义 基于 监控 数据 的 告警 规则 ， 规 则 会 触 帮 告警 。 一 旦 
Alermanager 收 到 告警 ， 就 会 通过 预定 义 的 方式 发 出 告警 通知 ， 文 持 的 
方式 包括 Email、PagerDuty、Webhook 等 。 


14.3.2 Prometheus Operator 架 构 


Prometheus Operator 的 目标 是 尽 可 能 简化 在 Kubernetes 中 部 普 和 维护 
Prometheus 的 工作 。 其 架构 如 图 14-32 所 示 。 
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图 14-32 
图 14-32 中 的 每 一 个 对 象 都 是 Kubernetes 中 运行 的 资源 。 
1. Operator 


Operator 即 Prometheus ”Operator， 在 Kubernetes 中 以 Deployment 运 
行 。 其 职责 是 部 署 和 管理 Prometheus Server， 根 据 ServiceMonitor 动 态 更 
新 Prometheus Server 的 监控 对 象 。 





2. Prometheus Server 


Prometheus Server 会 作为 Kubernetes 应 用 部 署 到 集群 中 。 为 了 更 好 地 
在 Kubernetes 中 管理 Prometheus，CoreOS 的 开发 人 员 专 门 定 义 了 一 个 命 
名 为 Prometheus 类 型 的 Kubernetes 定 制 化 资源 。 我 们 可 以 把 Prometheus 看 


作 一 种 特殊 的 Deployment， 它 的 用 途 融 是 专门 部 署 Prometheus Server. 


3. Service 


这 里 的 Service 就 是 Cluster 中 的 Service 资 源 ， 也 是 Prometheus 要 监控 
的 对 象 ， 在 Prometheus 中 叫 作 Target。 每 个 监控 对 象 都 有 一 个 对 应 的 
Service。 比 如 要 监控 Kubernetes SUA 束 得 有 一 个 与 Scheduler 对 应 
的 Service。 当 然 ，Kubernetes 集 群 默认 是 没有 这 个 Service 的 ， 
Prometheus ia 负责 创建 。 


4. ServiceMonitor 


Operator fe fle z/] 4s 5H Hf Prometheus) Target¥ Æ, ServiceMonitor st 
Target 的 抽象 。 比 如 想 监 控 Kubernetes Scheduler， 用 户 可 以 创建 一 个 与 
Scheduler Service 相 映射 的 ServiceMonitor 对 象 。Operator 则 会 发 现 这 个 新 
的 ServiceMonitor， 并 将 Scheduler 的 Targeti 过 加 到 Prometheus 的 监控 列表 
中 。 


ServiceMonitor 也 是 Prometheus Operator 专门 开发 的 一 种 Kubernetes 
定制 化 资源 类 型 。 


5. Alertmanager 


除了 Prometheus 和 ServiceMonitor，Alertmanager 是 Operator 开 发 的 第 
三 种 Kubernetes 定 制 化 资源 。 我 们 可 以 把 Alertmanager 看 作 一 种 特殊 的 
Deployment， 它 的 用 途 就 是 专门 部 车 Alertmanager 组 件 。 


14.3.3 à Prometheus Operator 


笔者 在 实践 时 使 用 的 是 Prometheus Operator 最 新 版 本 v0.14.0。 由 于 
页 目 开 发 迭代 速度 很 快 ， 部 署 方法 可 能 会 更 新 ， 必 要 时 请 参考 官方 文 


1. 下 载 最 新 源码 


git clone https://github.com/coreos/prometheus-operator.git 
cd prometheus-operator 


为 方便 管理 ， 创 建 一 个 单独 的 Namespace monitoring, Prometheus 
Operator 相 关 的 组 件 都 会 部 署 到 这 个 Namespace。 


kubectl create namespace monitoring 


2. Z7: Prometheus Operator Deployment 


helm install --name prometheus-operator --set rbacEnable-true-- 
namespace-monitoring helm/prometheus-operator 


Prometheus Operator 所 有 的 组 件 都 打包 成 Helm Chart, iiA E 
TI, 如 图 14-33 所 示 。 如 果 对 Helm 不 熟悉 ， 可 以 参考 前 面相 关 的 章 
"Ue 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ kubectl get --namespace-monitoring deployment prometheus-operator| 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE 
prometheus-operator-prometheus-operator 1 al 1 1 
ubuntu@k8s-master: ~$ 





图 14-33 


3. 安装 Prometheus、Alertmanager 和 Grafana 


helm install - -name prometheus -- 
set serviceMonitorsSelector.app-prometheus-- 
set ruleSelector.app-prometheus -- 
namespace-monitoring helm/prometheus 

helm install --name alertmanager -- 


namespace=monitoring helm/alertmanager 
helm install --name grafana --namespace=monitoring helm/grafana 


可 以 通过 kubectl get prometheus 查 看 Prometheus 类 型 的 资源 ， 如 图 
14-34 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get --namespace=monitoring prometheus 

NAME AGE 

prometheus 1d 

ubuntuék8s master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace-monitoring pod prometheus-prometheus-0 
NAME READY STATUS RESTARTS AGE 


prometheus-prometheus-@ 2/2 Running 0 1d 

ubuntuék8s master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace-monitoring service prometheus-prometheus 
NAME TYPE CLUSTER-IP EXTERNAL -IP PORTCS) AGE 
prometheus-prometheus NodePort 10.96.207.169 <none> 9090:30413/TCP 1d 
ubuntu@k8s-master :~$ 





图 14-34 


为 了 方便 访问 Prometheus Server， 这 里 已 经 将 Service 类 型 通过 
kubectl edit 改 为 NodePort。 


同样 可 以 查看 Alertmanager 和 Grafana 的 相关 资源 ， 如 图 14-35、 图 
14-36 所 示 。 


ubuntuék8s -master : ~$ 

ubuntuék8s-master:-$ kubectl get --namespace=monitoring alertmanager 

NAME AGE 

alertmanager 2d 

ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get --namespace=monitoring pod alertmanager-alertmanager-0 
NAME READY STATUS RESTARTS AGE 


alertmanager-alertmanager-Q9 2/2 Running 0 2d 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace-monitoring service alertmanager-alertmanager 
NAME INPE CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
alertmanager-alertmanager NodePort 10.103.53.199 <none> 9093:32758/TCP 2d 
ubuntu@k8s-master: ~$ 





图 14-35 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get --namespace-monitoring deployment grafana-grafana 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 

grafana-grafana 1 1 T 1 5h 

ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get --namespace=monitoring pod grafana-grafana-5fdf676c68-v7dlb 
NAME READY STATUS RESTARTS AGE 


grafana-grafana-5fdf676c68-v7dlb 2/2 Running 0 5h 
ubuntu@k8s-master: ~$ 

ubuntuék8s-master:-$ kubectl get --namespace=monitoring service grafana-grafana 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
grafana-grafana NodePort 10.109.107.156 <none> 80:32342/TCP 5h 
ubuntu@k8s-master : ~$ 





图 14-36 
Service 类 型 也 都 已 经 改 为 NodePort。 
4. 安装 kube-prometheus 


kube-prometheus 是 一 个 Helm Chart， 打 包 了 监控 Kubernetes 需 要 的 所 
有 Exporter 和 ServiceMonitor。 


helm install - -name kube-prometheus -- 
namespace-monitoring helm/kube-prometheus 


每 个 Exporter 会 对 应 一 个 Service， 为 Pormetheus 提 供 Kubernetes 集 群 


的 各 类 监控 数据 ， 如 图 14-37 所 示 。 


ubuntuek8s-master:-$ 

ubuntu@k8s-master:~$ kubectl get --all-namespaces service 

NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL - IP PORTCS) 
default kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 
kube-system ^ heapster ClusterIP 10.108.228.4 <none> 80/TCP 
kube-system — kube-dns ClusterIP — 10.96.0.10 «none» 53/UDP ,53/TC 


y: p p p ClusterIP None <none> 443/TCP 
|kube-system kube-prometheus-exporter-kube-controller-manager | ClusterIP <none> 10252/TCP 
kube-system kube-prometheus-exporter-kube-dns ClusterIP <none> 10054/TCP, 104 
kube-system kube-prometheus-exporter-kube-etcd ClusterIP <none> 4001/TCP 
kube-system kube-prometheus-exporter-kube-scheduler ClusterIP <none> 10251/TCP 
—fagsdtas — ETS J ClusterIP <none> 10250/TCP 
m kuberne shboard NodePort .110.199.111 <none> 443:31614/TC 
kube-system monitoring-grafana NodePort 1111,8.115 «none» 80:32314/TCP 
kube-system ^ monitoring-influxdb ClusterIP .99.44. «none» 8086/TCP 
kube-system — tiller-deploy ClusterIP : .247.7 «none» 44134/TCP 
kube-system ^ weave-scope-app NodePort $ .149.68 <none> 
monitoring alertmanager-alertmanager NodePort : .53.199 <none> 
monitoring alertmanager-operated ClusterIP <none> 
monitoring grafana-grafana NodePort s .107.156 <none> 80:32342/TCP 
| xporte ate | ClusterIP .100.157.79 «none» 80/TCP 
kube-prometheus-exporter-node ClusterIP : .108.197 «none» 9100/TCP 
monitoring prometheus-operated ClusterIP <none> 9090/TCP 
monitoring prometheus-prometheus NodePort 10.96.207.169 <none> 9090: 30413/T! 


ubuntu@k8s—master :~$ 
图 14-37 





每 个 Service 对 应 一 个 ServiceMonitor， 组 成 Pormetheus 的 Target 列 


表 ， 如 图 14-38 所 示 。 


ubuntu@k&8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace=monitoring servicemonitor 
NAME AGE 
alertmanager-alertmanager 2d 
kube-prometheus-exporter-kube-api 2d 
kube-prometheus-exporter-kube-controller-manager 2d 
kube-prometheus-exporter-kube-dns 2d 
kube-prometheus-exporter-kube-etcd 2d 
kube-prometheus-exporter-kube-scheduLer 2d 
kube-prometheus-exporter-kube-state 2d 
kube-prometheus-exporter-kubelets 2d 
kube-prometheus-exporter-kubernetes 2d 
kube-prometheus-exporter-node 2d 
prometheus-operator 2d 
prometheus-prometheus 1d 
ubuntu@k8s-master : ~$ 
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Prometheus Operator 相 关 的 所 有 Pod 如 网 14-39 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get pods --namespace-monitoring -o wide 

NAME READY STATUS RESTARTS IP NODE 
alertmanager-alertmanager-@ 2/2 Running 10.244.1.26 k8s-node2 
grafana-grafana-5fdf676c68-v7dlb 2/2 Running 10.244.1.30 k8s-node2 
kube-prometheus-exporter-kube-state-5ff8596498-lprrr 2/2 Running 10.244.2.31 k8s-node1 


kube-prometheus-exporter-node-6hbj7 1/1 Running 192.168.56.106 — k8s-nodel 
kube-prometheus-exporter-node-k59dm 1/1 Running 192.168.56.107 k8&s-node2 
kube-prometheus-exporter-node-t4cns 1/1 Running 192.168.56.105 k8s-master 
prometheus-operator-prometheus-operator-597f678b79-94qvw 1/1 Running 10.244.2.27 k8s-node1 
prometheus-prometheus-Q 2/2 Running 10.244.2.32 k8s-node1 


ubuntuek8s-master : ~$ 





图 14-39 


我 们 注意 到 有 些 Exporter 没 有 运行 Pod， 这 是 因为 像 API Server. 
Scheduler、Kubelet 等 Kubernetes 内 部 组 件 原生 就 支持 Prometheus， 只 雷 
要 定义 Service 束 能 直接 从 预定 义 端 口 获取 监控 数据 。 





通过 浏览 器 打开 Pormetheus 的 Web 
UI Chttp://192.168.56.105:30413/targets) ， 如 图 14-40 所 示 。 





= C © 192.168.56.105:30413/targets 


Targets 


alertmanager 
Endpoint State Labels 


http//10244.1.269093/metics a。 UP 


kube-prometheus-exporter-kube-dns 






Endpoint State Labels 
http//10.244.1.21:10054/metrics TUP ETE 
http://10.244.1.21:10055/metrics TUP pod-*kube-dne-54t 


kube-prometheus-exporter-kube-state 


Endpoint State Labels 


http://10.244.2.31:8080/metrics UP instance="10.244.2.31:8080" 


kube-prometheus-exporter-node 





Endpoint State Labels 

http://192.168.56.105:9100/metrics UP pod="kube-prometheus-exporte 
ETUEMUUIDTUESS 

httpy//192.168.56.106:9100/metrics UP pod="kube-promethous-exporte 
SS es 


图 14-40 


可 以 看 到 所 有 Target 的 状态 都 是 UP。 
5. 安装 Alert 规 则 


Prometheus Operator 提 供 了 默认 的 Alertmanager 告 警 规则 ， 通 过 如 下 
命令 安装 。 


Sed -ie 's/role: prometheus- 
rulefiles/app: prometheus/g' contrib/kube- 
prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 

sed - 
ie 's/prometheus: k8s/prometheus: prometheus/g! contrib/kube- 
prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 

sed -ie 's/job-zN"kube-controller-manager/jobz*N"kube-prometheus- 
exporter-kube-controller-manager/g' contrib/kube- 
prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 

sed -ie 's/job=\"apiserver/job=\"kube-prometheus -exporter -kube- 
api/g' contrib/kube-prometheus/manifests/prometheus/prometheus- 


k8s-rules.yaml 

sed -ie 's/jobzwN'"kube-scheduler/jobzN"kube-prometheus-exporter - 
kube-scheduler/g' contrib/kube- 
prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 

sed -ie  's/job=\"node-exporter/job=\"kube-prometheus-exporter - 
node/g' contrib/kube-prometheus/manifests/prometheus/prometheus - 
k8s-rules.yaml 

kubectl apply -n monitoring -f contrib/kube- 
prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 


6. 安装 Grafana Dashboard 


Prometheus Operator 定义 了 显示 监控 数据 的 默认 Dashboard， 通 过 如 
下 命令 安装 。 


sed -ie 's/grafana-dashboards-0/grafana-grafana/g' contrib/kube- 
prometheus/manifests/grafana/grafana-dashboards.yaml 
sed -ie 's/prometheus-k8s.monitoring/prometheus- 
prometheus.monitoring/g' contrib/kube- 
prometheus/manifests/grafana/grafana-dashboards.yaml 
kubectl apply -n monitoring -f contrib/kube- 
prometheus/manifests/grafana/grafana-dashboards.yaml 


打开 Grafana 的 Web UI Chttp://192.168.56.105:32342/) ， 如 图 14-41 
所 示 。 


G- 24 Home- & 


Home Dashboard 


Getting Started with Grafana 


(2 z 


1astal-Grafana 


Starred dashboards 


Recently viewed dashboards 
Pods 
Deployment 
Nodes 


Kubernetes Control Plane Status 





图 14-41 





Grafana 的 DataSource 和 Dashboard 已 自动 配置 ， 单 击 Home 就 可 以 使 
用 我 们 在 最 开始 讨论 过 的 那些 Dashboard 了 ， 如 图 14-42 所 示 。 
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144 小结 


本 章 我 们 实践 了 三 种 Kubernetes 监 控 方 案 。 


(1) Weave Scope 可 以 展示 集群 和 应 用 的 完整 视图 。 其 出 色 的 交互 
性 让 用 户 能 够 轻松 对 容器 化 应 用 进行 实时 监控 和 问题 诊断 。 


(2) Heapster 是 Kubernetes 原 生 的 集群 监控 方案 。 预 定义 的 
Dashboard 能 够 从 Cluster 和 Pods 两 个 层次 监控 Kubernetes 。 


(3) Prometheus Operator 可 能 是 目前 功能 最 全 面 的 Kubernetes 开 源 
监控 方案 。 除 了 能 够 监控 Node 和 Pod， 还 支持 集群 的 各 种 管理 组 件 ， 比 
如 API Server, Scheduler, Controller Manager 等 。 


Kubernetes 监 控 是 一 个 快速 发 展 的 领域 ， 随 着 Kubernetes 的 普及 ， 一 
定 会 涌现 出 更 多 的 优秀 方案 。 


215= Kubernetes£& ££ H m E XE 


Kubernetes 开 发 了 一 个 Elasticsearch 附 加 组 件 来 实现 集群 的 日 志 管 
理 。 这 是 Elasticsearch、Fluentd 和 Kibana 的 组 合 。Elasticsearch 是 一 个 搜 
E 引擎 ， 负 责 存 储 日 志 并 提供 查询 接口 ， Fluentd 负 责 从 Kubernetes 搜 集 

志 并 发 送 给 Elasticsearch; Kibana 提 供 了 一 个 Web GUI， 用户 可 以 浏览 
a 存储 在 Elasticsearch 中 的 日 志 ， 如 图 15-1 所 示 。 


kubernetes fluentd dee 
图 15-1 


1531 部 署 


Elasticsearch 附 加 组 件 本 身 会 作为 Kubernetes 的 应 用 在 集群 里 运行 ， 
其 YAML 配 置 文件 可 从 


https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/fluentd- 
elasticsearch 获 取 ， 如 图 15-2 所 示 。 


Branch: master» kubernetes / cluster / addons / fluentd-elasticsearch / 


pi, k8s-merge-robot Merge pull request #55509 from tallclair/psp-addons == L 





lia es-image Merge pull request #54215 from mrahbar/elasticsearch logging. discovery 
lia fluentd-es-image Add CRI log format support in fluentd. 

lig podsecuritypolicies Add optional addon PSPs 

E OWNERS Added coffeepac to ElasticSearch owners 

E README.md Refactored the fluentd-es addon files, moved the fluentd configuratio... 


=) es-service.yaml Adds the new addon-manager labels on cluster addon templates 





=) es-statefulset.yaml fluentd-elasticsearch add-on: Rename Elasticsearch Docker image tag 
=) fluentd-es-configmap.yaml Fix CRI fluentd config. 


=) fluentd-es-ds.yaml Fix CRI fluentd config. 





=) kibana-deployment.yaml fluentd-elasticsearch add-on: Upgrade API versions 














=) kibana-service.yaml Adds the new addon-manager labels on cluster addon templates 





图 15-2 


可 将 这 些 YAML 文 件 下 载 到 本 地 目录 ， 比 如 addons， 通 过 kubectl 
apply -f addons/ 部 车 ， 如 图 15-3 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f addons/ 
service "elasticsearch-Logging" created 
serviceaccount "elasticsearch-Logging" created 
clusterrole "elasticsearch-Logging" created 
clusterrolebinding "elasticsearch-logging" created 
statefulset "elasticsearch-Logging" created 
configmap "fluentd-es-config-v@.1.1" created 
serviceaccount "fluentd-es" created 
clusterrole "fluentd-es" created 
clusterrolebinding "fluentd-es" created 
daemonset "fluentd-es-v2.@.2" created 
deployment "kibana-logging" created 

service "kibana-logging" created 
ubuntu@k8s-master : ~$ 





图 15-3 








这 里 有 一 点 需要 注意 : 后 面 我 们 会 通过 NodePort 访 问 Kibana， 需 要 
注释 掉 kibana-deployment.yaml 中 的 环境 变量 SERVER_BASEPATH， 人 否 
则 无 法 访问 ， 如 图 15-4 所 示 。 


spec: 
containers: 
- name: kibana-logging 
image: docker.elastic.co/kibana/kibana:5.6.2 
resources: 


limits: 
cpu: 1000m 
requests: 
cpu: 100m 
env: 
- name: ELASTICSEARCH_URL 


value: http://elasticsearch-lo 


name: 
value: 
- name: XPACK. SECURITY. ENABLED 
value: 
ports: 
- containerPort: 
name: ui 
protocol: TCP 





图 15-4 


所 有 的 资源 都 部 署 在 kube-system Namespace 里 ， 如 图 15-5 所 示 。 


ubuntuék8s-master:-$ kubectl get --namespace-kube-system daemonset fluentd-es-v2.0.2 

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE 
fluentd-es-v2.0.2 2 2 2 2 2 «none» E 
ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get --namespace-kube-system pod -l "k8s-app-fluentd-es" 

NAME READY STATUS RESTARTS AGE 

fluentd-es-v2.0.2-2hjp4 1/1 Running 0 9m 

fluentd-es-v2.0.2-m4gq7 1/1 Running 0 9m 

ubuntu@k&8s-master : ~$ 





图 15-5 


DaemonSet fluentd-es 从 每 个 节点 收集 日 志 ， 然 后 发 送 给 
Elasticsearch， 如 图 15-6 所 示 。 


ubuntuék8s-master:-$ kubectl get --namespace-kube-system statefulset elasticsearch-logging 

NAME DESIRED CURRENT AGE 

elasticsearch-logging 2 Z 13m 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace=kube-system pod -l "k8s-app=elasticsearch-lLogging" 
NAME READY STATUS RESTARTS AGE 


elasticsearch-logging-®@ 1/1 Running 0 13m 

elasticsearch-logging-1 1/1 Running 0 13m 

ubuntuék8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace=kube-system service elasticsearch-logging 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
elasticsearch-logging NodePort 10.103.27.59 <none> 9200:32607/TCP 14m 
ubuntu@k8s-master: ~$ 





图 15-6 


\ 一 /一 


Elasticsearch 以 StatefulSet 资 源 运 行 ， 并 通过 Service elasticsearch- 
logging 对 外 提供 接口 。 这 里 已 经 将 Service 的 类 型 通过 kubectl edit 修 改 为 
NodePort。 


可 通过 http:/V192.168.56.106:32607/ 验 证 Elasticsearch 已 正常 工作 ， 如 
图 15-7 所 示 o 


= Œ © 192.168.56.106:32607 


{ 
"name" : "elasticsearch-logging-1", 
"cluster_name" : "kubernetes-logging", 
"cluster uuid" : "wRgkHHpNRGCtyQoSvpAIjA", 
"version" : ( 
"number" : "5.6.2", 
"build hash" : "57e20£3", 
"build date" : "2017-09-23T13:16:45.7032", 
"build snapshot" : false, 


"Lucene version" : "6.6.1" 
}, 
"tagline" : "You Know, for Search" 
} 
图 15-7 


Kibana 以 Deployment 资 源 运行 ， 用 户 可 通过 Service kibana-logging 访 
问 其 Web GUI。 这 里 已 经 将 Service 的 类 型 修改 为 NodePort， 如 图 15-8 所 
Z^ o 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get --namespace-kube-system deployment kibana-logging 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 

kibana-logging 1 1 1 al 21m 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace-kube-system pod -l "k8s-app-kibana-logging" 


NAME READY STATUS RESTARTS AGE 
kibana-logging-7879c88776-sfhnv 1/1 Running 0 21m 
ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get --namespace-kube-system service kibana-logging 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(CS) AGE 
kibana-logging NodePort 10.103.43.140 <none> 5601:30319/TCP 21m 
ubuntu@k8s-master : ~$ 





图 15-8 


v vo) 


通过 http://192.168.56.106:30319/ 访 问 Kibana， 如 图 15-9 所 示 。 





E C | © 192.168.56.106:30319/app/kibanast/management/kibana/index? g-() 


Management / Kibana 


A kibana Index Patterns Saved Objects Reporting Advanced Settings 


@ _ Discover c = 
No default index pattern. You Configure an index pattern 


Visualize must select or create one to " g 
canine, In order to use Kibana you must configure at least one index p 


Dashboard against. They are also used to configure fields. 


: Index pattern advanced options 
Timelion 


logstash-* 


Machine Learning 
Patterns allow you to define dynamic index names using * as a wildcard. 
Graphi Time Filter field name 6 refresh fields 


Dev Tools @timestamp 


Management Expand index pattern when searching [DEPRECATED] 


With this option selected, searches against any time-based index pattern| 
currently selected time range. 


Searching against the index pattern /ogstash-* will actually query Elastics| 
With recent changes to Elasticsearch, this option should no longer be neq 


_ Use event times to create index names [DEPRECATED] 


图 15-9 





Kibana 会 显示 Index Pattern 创 建 页 面 。 直 接 单 击 Create，Kibana 会 目 
动 完成 后 续 配置 ， 如 图 15-10 所 示 。 


Management / Kibana 


区 kibana Index Patterns Saved Objects Reporting Advanced Settings 


Visualize 


* logstash-* 


This page lists every field in the logstash-* index and the field's associated core type as recorded 
type of each field, changing field types must be done using Elasticsearch's Mapping AP! % 


Dashboard 


Timelion 


Machine Learning fields (113) scripted fields (0) source filters (0) 


Graph Q Filter 


Dev Tools name = type = searchable © = 

Management @timestamp [5 date 
MESSAGE string 
MESSAGE.keyword string 
PRIORITY string 
PRIORITY.keyword string 
SYSLOG FACILITY string 
SYSLOG FACILITY.keyword string 
SYSLOG IDENTIFIER string 
SYSLOG IDENTIFIER.keyword string 


_id string 


Sa) © D X «y *& D « ES «5€ 


.index string 
_score number 
_source _source 


-type 





© Collapse 


docker.container_id 
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这 时 ， 单 击 左上 角 的 Discover 就 可 以 查看 和 检索 Kubernetes 日 志 


如 图 15-11 所 示 。 





140 hits 


New Save Open Share Reporting <€ © Last15 minutes 


Search... (e.g, status:200 AND extension:PHP) Uses 





Add a filter + 
logstash-* 


Selected Fields 


Available Fields 


© @timestamp 


E 


E 


-type 
docker.container id 


t kubernetes containt 





kuberneres host 


kuberneres labels coi 





kubernetes labels. kBs... 
t kubernetes.labels ku. 
t kubernetes.labels po... 


kubernetes.labels.task 


kubernetes.labels.ver.. 
kubernetes.master url 
kubernetes.namespa... 


kubernetes.pod id 


Count 


November 20th 2017, 09:28:37.808 - November 20th 2017, 09:43:37.808 — Auto $ 





0929.00 09:30:00 09314 09:32:00 09:33:00 — 0934,00 09:37:00 2.38.01 





timestamp per 30 seconds 


Time „source 








November 20th 2017, 09:43:20.000 type: response @timestamp: November Z0th 2017, 09:43:20.000 tags: pid: 1 method: get 


statuscode: 200 req.url: /api/reporting/jobs/list_completed_since?since=2017-11-20T01%3A34%3A24. 35 


8Z req.method: get req.headers.host: 192.168.56.106:30319 req.h 





req.headers. 








req.headers.kbn-version: 5.6.2 req.header: 


iccept: application/json, text/plain, */* req.headers.kbn-system-api: 
ier-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.1 


connection: keep-alive 


true 


November 20th 2017, 09:43:10.000 type: response étimestamp: November 2@th 2017, 09:43:10.000 tags: pid: 1 method: get 


sta 





BZ req.method: get req.headors.host: 192.168.56.106:30319 reg.hea 





Code: 200 req.url: /api/reporting/jobs/list completed since?since-2017-11-20T013A343A24 .35 


rs.connection: keep-alive 


req.headers.accept: application/json, text/plain, */* req.headers.kbn-system-api: true 


req.headers.kbn-version: 5.6.2 req.headers.user-agent: Mozillo/S.0 (Macintosh; Intel Mac OS X 10.1 


November 20th 2017, 09:43:05.000 log: [httpd] 10.244.2.101 - root [20/Nov/2017:01:43:05 40000] "POST /write?consistency-&db-kBs&preci 


sion=&rp=default HTTP/1.1" 204 € 





ieapster/v1.4. 





" 2701288a-cd94-11e7-8365-000000000000 25607 


stream: stderr docker.container id: 293164a03c9cdc518d770bd6eb9b6204e68ce413390df c62f03d990553754b1 


1b kubernetes.contaimer name: influxdb kubernotes.namospace mame: kube-system 
684d6bb-cc75-11e7-94 


kubernetes.pod name: monitoring-influxdb-85cb4985d4-68czc kubernet: 





pod id: 


November 20th 2017. 09:42:59.000 tunes resnonse Atimestanp: Novemher 2Ath 2017. 00:42:50 000 tags: pidi J 


method. poet 
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, 


Kubernetes 日 志 管 理 系统 已 经 就 绪 ， 用 户 可 以 根据 需要 创建 自己 的 
Dashboard， 具 体 方法 可 参考 Kibana 官 方 文档 。 


15.2 小结 
Elasticsearch Hr 加 REIS 会 作为 Kubernetes 的 应 用 在 集群 里 运行 ， 
以 实现 集群 的 日 志 管 理 。 它 是 Elasticsearch、Fluentd 和 Kibana 的 组 合 。 
Elasticsearch 是 一 个 搜索 引擎 ， 负 责 存 储 日 志 并 提供 查询 接口 。 
Fluentd 人 负责 从 Kubernetes 搜 集 日 志 并 发 送 给 Elasticsearch。 


Kibana 提 供 了 一 个 Web GUI， 用 户 可 以 浏览 和 搜索 存储 在 
Elasticsearch 中 的 日 志 。 


写 在 最 后 





作为 Kubernetes 的 实战 教程 ， 我 们 已 经 到 了 该 收尾 的 时 候 。 

本 教程 涵盖 了 Kubernetes 最 最 重要 的 技术 : 集群 架构 、 容 器 化 应 用 
NEG. Scale Up/Down、 滚 动 更 新 、 监 控 检 查 、 集 群 网 络 、 数 据 管理 、 
监控 和 日 志 管 理 ， 通 过 大 量 的 实验 探讨 了 Kubernetes 的 运行 机 制 。 


这 本 教程 的 目标 是 使 读者 能 够 掌握 实施 和 管理 Kubernetes 的 必需 技 
能 ， 能 够 真正 将 Kubernetes 用 起 来 。 


为 了 达到 这 个 目标 ， 每 一 章 都 设计 了 大 量 的 实践 操作 环节 ， 通 过 截 
图 和 日 志 帮 助 读者 理解 各 个 技术 要 点 ， 同 时 为 读者 目 己 实践 Kubernetes 
提供 详尽 的 参考 。 

本 教程 对 读者 应 该 会 有 两 个 作用 : 


(1) 初学 者 可 以 按照 章节 顺序 系统 地 学 习 Kubernetes， 并 通过 教程 
中 的 实验 掌握 Kubernetes 的 理论 知识 和 实 操 技能 。 


(2) 有 经 验 的 运 维和 人 员 可 以 将 本 教程 当 作 参考 材料 ， 在 实际 工作 
中 有 针对 性 地 奉 看 相关 知识 点 。 


希望 读者 能 够 通过 本 教程 打下 扎实 基础 ， 从 容 地 运 维 Kubernetes， 
并 结合 所 在 公司 和 组 织 的 实际 需求 搭建 出 实用 的 容器 管理 平台 。 


最 后 祝 大 家 使 用 Kubernetes 愉 快 ! 
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